Database schema management


#1

What is the best way to manage your database schema with Meteor/Mongo?


#2

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.


#3

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.


#4

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.


#5

+1. Aldeed’s packages are good, except the autoform. Looking forward to a official forming solution. Maybe it should be one thing about Blaze.


#6

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.)


#7

A form package you might want to check (bad doc but good architecture):

About template inheritance:


#8

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?


#9

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.