Models, ORM, Polymorphism & Migrations

Showing 1-8 of 8 messages
Models, ORM, Polymorphism & Migrations Daryl Antony 9/25/12 5:26 AM
Hi there.

I'm stepping into the meteor/mongo world, coming from django/rdbms/django models and 'south' schema and data migrations... and so, am trying to loosen my thinking to fit in.

I have a few questions:
  • Will Meteor have 'models' (I've seen mention of them)?
    • will these models be defined with 'fields'? (I've used Backbone recently, consuming an API -- the JSON structure dictated the 'field' structure of the 'backbone model' -- yet, how might this be done in Meteor? (i.e. when the datastore is mongodb which is being 'told' by the Meteor application, how to store data.
  • I've seen mention of an upcoming Meteor ORM.
    • To me, an ORM can be a scheme to relate objects to one another, like 'Shop has many Products' (similar to 'backbone-relational' perhaps...
    • What does ORM mean in the Meteor/Mongo context?
  • How might we manage changes in data structure or schema?
    • Say we have a whole lot of Products (stored as Mongo documents) with a field 'name' -- and we want to change it to 'title'.  Is there a way to 'migrate' the data structure -- similar to which we might do with Django's South?
Polymorphism

I've been working on a 'cart/ecommerce' project in django, using django-polymorphic and referencing the REA (Resources, Events, Agents) accounting model, such that (python):

class Resource(PolymorphicModel):
   #...

class Product(Resource):
   #...

class Book(Product):
    isbn = models.CharField()

class Food(Product):
   per_kg_price = ....

... and so on.

I'm looking to replicate this inheritance in my Meteor project, and associated 'duck typing' -- how might this be possible in Meteor?


Re: [meteor-talk] Models, ORM, Polymorphism & Migrations Tom Coleman 9/25/12 7:05 PM
Hi Daryl,

I'll try to give my 2c on the questions; I'd be interested to hear what the devs have to say.

On Tuesday, 25 September 2012 at 10:26 PM, Daryl Antony wrote:

Hi there.

I'm stepping into the meteor/mongo world, coming from django/rdbms/django models and 'south' schema and data migrations... and so, am trying to loosen my thinking to fit in.

I have a few questions:
  • Will Meteor have 'models' (I've seen mention of them)?
    • will these models be defined with 'fields'? (I've used Backbone recently, consuming an API -- the JSON structure dictated the 'field' structure of the 'backbone model' -- yet, how might this be done in Meteor? (i.e. when the datastore is mongodb which is being 'told' by the Meteor application, how to store data.
There will be support for associating a ctor (javascript constructor) with a Collection, so you can attach a prototype to all the objects coming out of that collection (read: instantiate them as a class).

This will enable a lot of things for such objects, including:
- easy saving / updating
- deriving and defaulting values
- validation
- auto form building / reading
- unsaved reactive models

How much (if any) of the above functionality will come baked into Meteor (perhaps in a Meteor.Document class) is unknown, although it will certainly be possible for a 3rd party smart package to provide it.

  • I've seen mention of an upcoming Meteor ORM.
    • To me, an ORM can be a scheme to relate objects to one another, like 'Shop has many Products' (similar to 'backbone-relational' perhaps...
    • What does ORM mean in the Meteor/Mongo context?
I think there may be more resistance to the idea of an ORM. At least while mongo is the only supported data backend, it makes less sense as mongo is intended to be used in a far more denormalized way than a traditional RDMS. So the need for joins is much less pressing.

On the other hand, there's nothing stopping such functionality from being baked into a 3rd party model package as far as I can see. I wouldn't wait for something to come from core here though. (Tell me if I'm wrong guys!) 
  • How might we manage changes in data structure or schema?
    • Say we have a whole lot of Products (stored as Mongo documents) with a field 'name' -- and we want to change it to 'title'.  Is there a way to 'migrate' the data structure -- similar to which we might do with Django's South?
This is needed!

In fact I was thinking the other day that the more general ability to run node.js scripts on the server in the context of the meteor app is needed (much like rails runner, not sure of the Django equivalent). Migrations is one (and probably the most important) thing here, but other things that come to mind are:
- tests
- analytics
- batch jobs
Polymorphism

I've been working on a 'cart/ecommerce' project in django, using django-polymorphic and referencing the REA (Resources, Events, Agents) accounting model, such that (python):

class Resource(PolymorphicModel):
   #...

class Product(Resource):
   #...

class Book(Product):
    isbn = models.CharField()

class Food(Product):
   per_kg_price = ....

... and so on.

I'm looking to replicate this inheritance in my Meteor project, and associated 'duck typing' -- how might this be possible in Meteor?

Is this a more general JS question? Certainly inheritance is possible in javascript.

If you are talking about mongo + collections, then the lassiez-faire nature of NoSQL means that there really isn't any problem at all with doing this.

Hope that helps!

Cheers,
Tom
Re: [meteor-talk] Models, ORM, Polymorphism & Migrations Daryl Antony 9/25/12 8:54 PM
Thanks Tom.  Great to get the discussion going.

ORM

I suppose, and I've done this in a meteor test project somewhat, I'm looking to do things like:

Carts = new Meteor.Collection('carts')
CartItems = new Meteor.Collection('cart_items')
Products = new Meteor.Collection('products')

cart = Carts.findOne({'user': 'daryl'})
cart.cart_items
> an array of CartItem 'documents'

product = cart.cart_items[0].product
product
> "Apple" // a Mongo "Products" Document

product.parent
> "Resource: Apple" // a Mongo "Resource" document that is the parent of Product.

Perhaps it doesn't matter how its stored by mongo -- just that it is.

If this is an 'incorrect' way to use mongo/meteor -- how might I construct something like a 'cart' that has 'cart_items' ?

Is this what an ORM is? Just a means to map object relationships to one another?  Or is it more a term tied to an underlying RDBMS?

Models

Sounds promising on that front.  Good.

(I'd wondered what would happen if we stored a Backbone model inside a Document // perhaps I'll experiment)

Polymorphism

Yes, I've investigate this in terms of JS... and all seems doable -- its more that, how do work with these structures in terms of Meteor collections/documents:

Animals = new Meteor.Collection('animals')
Dogs = new Meteor.Collection('dogs')

??

Thanks Tom!
Re: [meteor-talk] Models, ORM, Polymorphism & Migrations Tom Coleman 9/25/12 9:05 PM

On Wednesday, 26 September 2012 at 1:54 PM, Daryl Antony wrote:

Thanks Tom.  Great to get the discussion going.

ORM

I suppose, and I've done this in a meteor test project somewhat, I'm looking to do things like:

Carts = new Meteor.Collection('carts')
CartItems = new Meteor.Collection('cart_items')
Products = new Meteor.Collection('products')

cart = Carts.findOne({'user': 'daryl'})
cart.cart_items
> an array of CartItem 'documents'

product = cart.cart_items[0].product
product
> "Apple" // a Mongo "Products" Document

product.parent
> "Resource: Apple" // a Mongo "Resource" document that is the parent of Product.

Perhaps it doesn't matter how its stored by mongo -- just that it is.

If this is an 'incorrect' way to use mongo/meteor -- how might I construct something like a 'cart' that has 'cart_items' ?
I think you'd store this in mongo as:

 cart: {items: [{product_id: X, product_name: 'Macbook Pro', price: 1233.23}, ..]}

The idea here is that you've denormalized everything out of the product that you need to deal with the cart, so it would be rare to ever have to look up the Products collection when dealing with Carts. Certainly there's no need for CartItems.

I'm not an expert on this (I'm more experienced with relational stuff too), but I'm pretty sure that's how you'd do it in mongo.
Is this what an ORM is? Just a means to map object relationships to one another?  Or is it more a term tied to an underlying RDBMS?
Yeah, the term ORM relates to dealing with the inconsistency between objects (with lists and links etc) and the flat tables that exist in RDBMs. In a NoSQL world, there's less of a problem, and thus need for ORMs. This article explains it really well: http://martinfowler.com/bliki/OrmHate.html 
Polymorphism

Yes, I've investigate this in terms of JS... and all seems doable -- its more that, how do work with these structures in terms of Meteor collections/documents:

Animals = new Meteor.Collection('animals')
Dogs = new Meteor.Collection('dogs')
I think you'd just have an Animals collection. It depends on what you are trying to do of course.

Tom 

Re: Models, ORM, Polymorphism & Migrations Daryl Antony 9/25/12 9:22 PM
Hey Tom.  You're in Melbourne?

We should have a Melbourne Meteor hangout :)
Re: [meteor-talk] Re: Models, ORM, Polymorphism & Migrations Tom Coleman 9/25/12 9:27 PM
Yup. Sounds like fun :)
--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/meteor-talk/-/yA6nzkxvsVAJ.
To post to this group, send email to meteo...@googlegroups.com.
To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.

Re: [meteor-talk] Models, ORM, Polymorphism & Migrations qdong333 9/25/12 9:53 PM
Hi guys,

I am new to mongo, too. But I would like to offer what I read about schema design in mongo:
http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-EmbeddingandLinking

Hope this helps a little.

As I understand it, the question to ask is: how repetitive you get, vs. how many server-query round trips you get.

So for the cart example, I would still have a Product collection with all product details, but I may want to add some short fields in elements of the itmes[] array, such as "name", "model", "manufacturer", or whatever you want users to see without doing another query. (Meteor's use of mini-mongo cerntainly reduced round trips to server, but it will add to initial subscription traffic and loading time, if you have too much data repetition.)

If we have a separate Product collection, maybe we can even do a timed subscription call to get product details after enabling user for app interaction.

Thanks,

Qichao
--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To post to this group, send email to meteo...@googlegroups.com.
To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.

Re: [meteor-talk] Models, ORM, Polymorphism & Migrations Daryl Antony 10/13/12 2:43 PM
Thanks for the reply Qichao.

I'm beginning to think that a combination of a mongodb data store, and restful api, say, based on django/tastypie/rdms might be a good way to achieve bests of both worlds.

Of course, prioritising data that needs to be 'reactive' in Mongo collections.

I've been amassing a lot of experience using backbone //  backbone-relational // backbone-tastypie // tastypie/django // rdms -- and can easily populate a whole system of related backbone collections & models in a single api call.

and having solid 'south' driven schema migrations on the django side makes a lot of sense to me.

That being said -- I'm forever priming my 'mongo' brain with use cases and solving problems 'differently'.  The journey continues.