What is the best way to manage your database schema with Meteor/Mongo?
3 Likes
We use aldeed:simple-schema to maintain a consistent db. If we need to add a field then we add it to the schema and make sure that we migrate all old documents to match the new schema changes when we push to production.
1 Like
The community standard is the aldeed:collection2 package, which includes aldeed:simple-schema (as mentioned by @khamoud). collection2 wraps the Mongo.Collection insert, update and upsert methods, applying your schema rules each time there is a change to the contents of a document, so you can make sure that what is going into your database is always valid. Itās a powerful, flexible, well-maintained package with wide adoption.
2 Likes
Oh lord, the aldeed packagesā¦
Itās friday night and Iāve had a few Belgian beers, so let me tell you about my experience with the aldeed packages the last few days. Mainly writing this to get some frustrations off my chest, so feel free to skip reading.
As a beginner to Meteor the aldeed packages were like a mountain I had been postponing to climb for a few weeks. From what I had heard about them they seemed just awesome and are like the holy grail to crud operations in Meteor. My spaghetti code for forms and db operations, with its many āif statementā nests to the xāth degree, was purring just fine but sure didnāt look pretty. I knew the aldeed packages were the solution to this, just hadnāt felt up to it yet to put in the time to learn about them.
So a few days ago I decided that that should be over with and I really just needed to get to it. Started off with a day of just reading the GitHub readmeās. Yes that took me a day, like I said Iām a beginner and it took a day to kind of get the hang of it. Went from Simple Schema to Autoform and on to Collection2. In hindsight, seeing how theyāre written I probably should have read them the other way around.
The next day, from early in the morning, was spend trying to implement autoform. Donāt think Iāve ever felt this much urge to throw with things. Everything I tried didnāt seem to work or it only worked half assed. Shot off a million questions into #meteor IRC space, pretty much the only response I got back was that people didnāt use autoform as it wasnāt customisable enough. The concept of Autoform sure seemed awesome to me though so I kept trying. If only I could have found some examples or tutorials of implementations using methods. Writing allow/denies always seemed messy to me, so I prefer using methods. Autoform just says itās possible to do so but gives no proper examples of how to handle it.
To a newbie each of the 3 readmeās seemed to have different ways of doing things, especially in the ways of validating. I think Iāve flipped back and forward a couple thousand times between them in the last few days trying out different things.
Late at night I finally found out the reason why I just couldnāt get Autoform to work properly. After much googling I just happened to run into an issue report. Apparently Autoform has an insurmountable problem with recursions in Firefox on Ubuntu. Exactly what I had been using to develop with.
Well that was the end of Autoform for me, I really loved the idea of using it. But getting it to work with methods just seemed too much of a pain in the ass. And like we say in the Netherlands; the bug was the drop that spilled over the edge of the bucket.
Next day was spend cleaning up Autoform code and continuing on with just Collection2. Still lots of trying to get methods to work properly, but slowly progress was being made. Only real hiatus was spending about 5 hours figuring out why I couldnāt get the SimpleSchema field rule unique to work properly. Apparently it has a bug with mongoā¦
So in conclusion; I now quite like Collection2, my code is much cleaner for it. Iād like to shoot Autoform in the face. Learned that if things donāt work its quite possible itās not just my lack of understanding on how to use a package but could also very well be a bug.
End rant.
2 Likes
+1. Aldeedās packages are good, except the autoform. Looking forward to a official forming solution. Maybe it should be one thing about Blaze.
As per comment of Eric Dobbertin (aka āaldeedā) in https://groups.google.com/forum/#!topic/meteor-talk/AVPdeDgtw94 that aldeed:collection2 and dburles:collection-helpers meet all his data modeling needs, my question is: How is inheritance handled? (A small code sample demonstrating as such would be much appreciated.)
A form package you might want to check (bad doc but good architecture):
About template inheritance:
1 Like
The template inheritance is interesting, but letās say I only want to do ābackendā modeling without any templates, and Iām using aldeed:collection2 and dburles:collection-helpers. Can I do inheritance without resorting to templates?
Thanks to everybody for your replies and suggestions.
So, aldeed:collection2 is the choice and I suppose that percolate:migrations is the best package available to manage migrations. What I found out is that now that my applications has thousand of lines of code not having a good strategy within the framework to manage database schema and migrations ā like Rails did since the early days ā itās a true nightmare.