È 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
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
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:
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", ,
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});
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