Kan Meteor korrekt håndtere data opdateret eksternt direkte til MongoDB-databasen?

Meteor er konfigureret til at oprette forbindelse til en ekstern mongodatabase . Du har mongo pakket på en lokal udviklingsapp, men det er kun for komfort og nem integration.

I produktionen skal du altid forbinde Meteor til din kørende Mongo-instans ved hjælp af MONGO_URL miljøvariabel .

Bonus:du kan indstille MONGO_URL selv i dev-tilstand for at oprette forbindelse til en specifik db i dev-tilstand. Vær opmærksom på, at du kan CRUD alt på denne db, brug med omhu.

Under motorhjelmen bruger Meteor node-mongo-driveren. Du er grundlæggende i stand til at bruge hele denne drivers API (se dette indlæg for detaljer om, hvordan man kalder indfødte Mongo-metoder)

Med Meteors publikations-/abonnementssystem du styrer som udgangspunkt, hvilke data der offentliggøres til kunden. Publikationer kører hver gang dataene ændres (svarende til observatørmønster).

Hvis alle dine kunder abonnerer på dataene i en samling, vil de få opdateringerne, når samlingen er opdateret. Og nu kommer du til din mest eftersøgte funktion:dette virker også, hvis disse data er opdateret af en ekstern kilde.

Det fungerer også med meget hurtige opdateringsintervaller. Jeg arbejdede på et nyligt projekt, hvor enorme mængder data er blevet opdateret via python på en Mongo-DB-samling. Meteor-appen lyttede til den og viste dataene til klienterne i "realtid" (eller hvad brugerne opfatter som realtid).

Der er dog nogle faldgruber, og det er godt at kende dem på forhånd.

Meteor opretter dokumenter med en _id af typen streng og ikke Mongo.ObjectID . Den er dog i stand til at læse den og skrive den hvis du bruger den korrekt .
Meteor omslutter samlinger med en egen API der integrerer samlingen bedst med dens fibers baseret miljø. Hvis du har brug for at bruge funktionalitet ud over, kan du læse her og her .
Returnerede markører opfører sig lidt anderledes, men som med samlinger er der også alle indbyggede funktioner tilgængelige, hvis du modtager markøren fra en rawCollection
Dobbelttjek de datatyper, du bruger på dine samlinger. Hold dig for eksempel til de samme datotyper (som ISODate), så der ikke er nogen utilsigtede fejl efter en opdatering. Der er også en Meteor-pendant til mongoose navngivet simpl-schema (npm-pakke ), hvilket er en god måde at holde struktur på dine samlinger.

Opsummeret, hvis du overvejer det meste af Meteor-guiden og API-dokumenterne, bør du være på et godt spor, da integrationen af eksternt opdaterede samlinger normalt kører meget godt, og det handler mest om at forstå pub-/undersystemet for at få det til at køre.

Rediger:

Ja det gør det, men du skal være opmærksom på en anden forespørgsel. Hvis det (eksternt oprettede) dokument har følgende værdi:

{ "_id" : ObjectId("4ecc05e55dd98a436ddcc47c") }

Så skal du ændre din (Meteor) forespørgsel fra

collection.findOne("4ecc05e55dd98a436ddcc47c") // returns undefined

til

collection.findOne({ "_id" : new Mongo.ObjectID("4ecc05e55dd98a436ddcc47c") }) // returns { _id: ObjectID { _str: '4ecc05e55dd98a436ddcc47c' } }

Samme mønster fungerer til oprettelse af dokumenter. I stedet for

collection.insert({ foo:'bar' })

du sender et nyoprettet ObjectID:

collection.insert({ foo:'bar', _id: new Mongo.ObjectID() })

Hvis du opretter dokumenter i Meteor med metoden ovenfor, skal du ikke bekymre dig om _id være en streng.

Udover at dokumenter er, som de skal være (se dataformatbroen ). Men hvis der er en undtagelse, du fandt, som ikke er blevet nævnt her, er du velkommen til at kommentere, da dette også kan være vigtigt for andre brugere.