I'm currently developing a Meteor application which will be based on different packages (maybe created by different developers).
My question is if there's a meteor'ish way to namespace collections so that they won't collide with other available collections.
For example, I have a package which uses the collection with the name 'todos' and another one which may also include a collection with the name 'todos'. Is there a way to namespace these collections (e.g. with their package-Name prepended)?
I've found out that there's an option for namespacing in MongoDB with a '.':
http://docs.mongodb.org/manual/faq/developers/#what-is-a-namespace-in-mongodb
Is this also the best way to namespace collections in Meteor?
Coming to Meteor with a Rails background, I can remember that you can create namespaced Engines in rails (which also creates namespaced database-Tables). Is there something similar in Meteor?
The closest I came was with this Issue I've found:
https://github.com/CollectionFS/Meteor-cfs-gridfs/issues/6
Thanks in advance!
Using a period in the collection name is a perfectly fine namespacing scheme for Meteor collections just as it is if you were using MongoDB alone.
var TodoCollection = Meteor.Collection('packageName.todos');
Packages such as CollectionFS use this technique to avoid collection name collisions.
Related
Could anyone please tell me how MongoDB can be used with YII?
How can we create controller and model functions using Gii if the database used is MongoDB?
I've used YiiMongoDBSuite (YMDS), which has some very rough support for Gii. You can generate starter classes, but given that MongoDB does not have a fixed schema you will need to edit the model to make them useful. There is an odd kludge that lets you generate MongoDB models from a SQL table, but this seems more effort than it's worth.
YMDS' EMongoDocument class extends the standard Yii CModel class, so this is a useful base if you want to build apps with CRUDS.
The unfortunate caveat is that YMDS is no longer maintained by the original author, and there are a few community forks to chose between.
The way of creating controllers is same as usual but you have to use an extension to talk to mongoDB from Yii ,
You need to use direct Mongo suite of yii . It is an extension which has a collection of components for the mongoDB .
Once many teams work with the same mongodb database there needs to be some way to express what each document may contain. Otherwise the document will end be having "email", "mail", "email_addr" fields added by each team. What's the best way to represent this for the purpose of communication across teams?
Obviously, the best way is what the team is most comfortable with. It can be UML, whiteboard drawings, XML mappings, model code files, maybe even haiku poems :)
I personally prefer using an ODM (mongoid). It encourages you to specify all fields in the model class. Then you just need one glance at it to understand the schema.
What you can do is create your Objects first in a set of commons that all team members import into their projects. If you change schema design, you update Commons project and all team members import latest.
It's more about process and project management and less about technology given Mongo's schema-less design. One thing we find helpful is design your Tests first and lately, SoapUI and LoadUI have been excellent tools. Once you define your tests, it can stub the returns for you and produces HTML documentation you can distribute to team.
Check out: http://www.soapui.org/REST-Testing/working-with-rest-services.html
When you create collection, just add to it some first "reference" object that would have all the fields/sub-objects that object of this collection can possibly have and use it as "schema". You can even write validator that would check that new objects conform to this reference object.
I have the following collections:
Client contains Product contains Project contains Task and
Company contains Subsidiary contains Department contains Users (and user contains custom properties)
What is the best practice? How to use mongodb more efficiently?
As for me, Users and Projects will be changed more often and should be defined as separate collections.
What is your advise?
There is no unified answer for you question, as MongoDB allows you to do both embedding and reference.
But here are some tips: don't bloat a collection, because querying the elements deep below might be hard, especially if you're going to use lists.
If you are able to prototype, try embedding the collections first and then write a unit test which will add/remove/query projects and users. If that would work, then there's no need to reference them.
We are using mongodb with c#. We are trying to figure out a way to keep our collection consistent seamlessly. Right now, if a developer make any changes to the class structure(add a field or change data type or changing the property within a nested class) he/she has to change the mongo collection manually.
Its a pain as our project is growing and the developers working on the project keeps increasing. Was wondering whether someone already have figured out a way to manage this issue.
Research
I found a similar question. however, couldn't find the solution.
Found a way to find all properties Finding the properties; however, datatype and nested documents becomes an issue.
If you want to migrate gradually as records are accessed you need to follow a few simple rules:
1) If you add a field it had better be nullable or have a default value specified.
2) Never rename fields, never change field types
- Instead always add new fields, add migration code, remove the old fields only when all documents have been migrated over.
For prototyping with MongoDB and C# I build a dynamic wrapper ... that lets you specify your objects using only interfaces (no classes needed), and it lets you dynamically add new interfaces to an existing object. Not ready for production use but for prototyping it saves a lot of effort and makes migration really easy.
I am using a custom database (MongoDB) with TG 2.1 and i am wondering where the proper place to store the PyMongo connection/database instances would be?
Eg, at the moment they are getting created inside of my inherited instance of AppConfig. Is there a standard location to store this? Would shoving the variables into the project.model.__init__ be the best location, given that under SQLAlchemy, the database seems to commonly be retrieved via:
from project.model import DBSession, metadata
Anyway, just curious what the best practice is.
As of TurboGears 2.1.3, MongoDB support is integrated via the Ming ORM. I would look at a quickstarted project using the --ming option to get best practices if you want to do some customization: http://turbogears.org/2.1/docs/main/Ming.html