Utilizzo di più database Mongodb con Meteor.js

È ansible che 2 Meteor.Collections dati da 2 diversi server di database mongdb?

 Dogs = Meteor.Collection('dogs') // mongodb://192.168.1.123:27017/dogs Cats = Meteor.Collection('cats') // mongodb://192.168.1.124:27017/cats 

Aggiornare

Ora è ansible connettersi a database remoti / multipli:

 var database = new MongoInternals.RemoteCollectionDriver(""); MyCollection = new Mongo.Collection("collection_name", { _driver: database }); 

Dove è un url mongodb://127.0.0.1:27017/meteor come mongodb://127.0.0.1:27017/meteor (con il nome del database)

C’è uno svantaggio in questo momento: No Oplog

Vecchia risposta

Al momento questo non è ansible. Ogni app meteorica è associata a un database.

Ci sono alcuni modi per aggirare questo problema, ma potrebbe essere più complicato che valga la pena:

Un’opzione – Usa un’app Meteore separata

Nell’altra app meteorica (esempio in esecuzione alla porta 6000 sulla stessa macchina). È ancora ansible avere reattività, ma è necessario eseguire il proxy inserimenti, rimuove e aggiornamenti tramite una chiamata di metodo

Server:

 Cats = Meteor.Collection('cats') Meteor.publish("cats", function() { return Cats.find(); }); Meteor.methods('updateCat, function(id, changes) { Cats.update({_id: id}, {$set:changes}); }); 

La tua app Meteor attuale:

 var connection = DDP.connect("http://localhost:6000"); connection.subscribe("cats"); Cats = Meteor.Collection('cats', {connection: connection}); //To update a collection Cats.call("updateCat", ,  

Un'altra opzione: connessione mongodb personalizzata

Questo utilizza il driver nativo js mongodb del nodo.

Questo si sta connettendo al database come se dovessi farlo in qualsiasi altra app js del nodo.

Non è disponibile reattività e non è ansible utilizzare le new Meteor.Collection tipi new Meteor.Collection .

 var mongodb = Npm.require("mongodb"); //or var mongodb = Meteor.require("mongodb") //if you use npm package on atmosphere var db = mongodb.Db; var mongoclient = mongodb.MongoClient; var Server = mongodb.Server; var db_connection = new Db('cats', new Server("127.0.0.1", 27017, {auto_reconnect: false, poolSize: 4}), {w:0, native_parser: false}); db.open(function(err, db) { //Connected to db 'cats' db.authenticate('', '', function(err, result) { //Can do queries here db.close(); }); }); 

Questo è effettivamente ansible, utilizzando un’interfaccia interna:

 var d = new MongoInternals.RemoteCollectionDriver(""); C = new Mongo.Collection("", { _driver: d }); 

La risposta è SI : è ansible impostare più Meteor.Collections per recuperare i dati da diversi server di database mongdb.

Come risposta di @Akshat, puoi inizializzare la tua istanza MongoInternals.RemoteCollectionDriver , attraverso la quale è ansible creare Mongo.Collection .

Ma ecco qualcosa di più di cui parlare. Essendo contrario alla risposta di @Akshat, trovo che il supporto di Oplog è ancora disponibile in tale circostanza.

Quando si inizializza il MongoInternals.RemoteCollectionDriver personalizzato, NON dimenticare di specificare l’URL Oplog:

 var driver = new MongoInternals.RemoteCollectionDriver( "mongodb://localhost:27017/db", { oplogUrl: "mongodb://localhost:27017/local" }); var collection = new Mongo.Collection("Coll", {_driver: driver}); 

Sotto il cappuccio

Come descritto sopra, è abbastanza semplice triggersre il supporto di Oplog. Se vuoi sapere cosa è successo sotto queste due righe di codici, puoi continuare a leggere il resto del post.

Nel costruttore di RemoteCollectionDriver , verrà creato un MongoConnection sottostante:

 MongoInternals.RemoteCollectionDriver = function ( mongo_url, options) { var self = this; self.mongo = new MongoConnection(mongo_url, options); }; 

La parte difficile è: se MongoConnection viene creato con oplogUrl fornito, un OplogHandle verrà inizializzato e inizierà a codificare Oplog ( codice sorgente ):

 if (options.oplogUrl && ! Package['disable-oplog']) { self._oplogHandle = new OplogHandle(options.oplogUrl, self.db.databaseName); self._docFetcher = new DocFetcher(self); } 

Come descritto in questo blog : Meteor.publish richiama internamente Cursor.observeChanges per creare un’istanza ObserveHandle , che tiene automaticamente traccia di eventuali modifiche future avvenute nel database.

Attualmente esistono due tipi di driver per gli osservatori: il precedente PollingObserveDriver che utilizza una strategia Poll-and- OplogObseveDriver e OplogObseveDriver , che utilizza in modo efficace Oplog-tailing per monitorare le modifiche dei dati. Per decidere quale applicare, observeChanges come segue ( codice sorgente ):

 var driverClass = canUseOplog ? OplogObserveDriver : PollingObserveDriver; observeDriver = new driverClass({ cursorDescription: cursorDescription, mongoHandle: self, multiplexer: multiplexer, ordered: ordered, matcher: matcher, // ignored by polling sorter: sorter, // ignored by polling _testOnlyPollCallback: callbacks._testOnlyPollCallback }); 

Per rendere canUseOplog vero, è necessario soddisfare diversi requisiti. Un minimo uno è: l’istanza di MongoConnection sottostante dovrebbe avere un OplogHandle valido. Questo è il motivo esatto per cui è necessario specificare oplogUrl durante la creazione di MongoConnection