component / model

Minimalistic extensible data models
122 stars 40 forks source link

nested models and collections #32

Closed ianstormtaylor closed 11 years ago

ianstormtaylor commented 11 years ago

curious to know what your guys' thoughts are on nested models and collections. personally i find them super useful, if not necessary for most of my stuff.

the other thing is, i think they should be in component core because otherwise we're going to end up with problems getting support for it in everyone's model and collection plugins...

jkroso commented 11 years ago

Do you mean creating a model hierarchy like the DOM? Or just the ability to put a model on an attribute. e.g.

new Model({
  child: new Model
})
ianstormtaylor commented 11 years ago

not sure what you mean by creating a model hierarchy like the DOM, but yeah the general ability to have nested models/collections in attributes

one of the pieces needed is a model.parse so that JSON objects/arrays can be transformed into models/collection when fetched from the server

jkroso commented 11 years ago

Oh yup. Connecting stuff in your app code isn't too bad I've been doing a bit of that. But having those connections serialized and rehydrated is a tricky problem which I haven't got around to tackling. I'm going to have to eventually though to complete my current project. JSON won't cut it though it'll have to be something like edn

tj commented 11 years ago

personally I think this is where most ORM-ish things go totally wrong, they have some nice conveniences when it comes to common boilerplate but I think once they get into associations and more complex querying they cause more grief than anything else. That's the main reason I wont end up adding many query related methods, best to just stub those out manually IMO

ianstormtaylor commented 11 years ago

curious: do you guys go for the nested approach and having each parent pass down just enough information for the child to be able to fetch/save itself? or do you go for a completely flat approach with references and some singleton that connects the two? or something better than either?

we we're trying to work through both situations last night and getting screwed either way :)

tj commented 11 years ago

we dont have too much relational stuff to be honest, but at least with my ORM experience I would rather do the slightly more verbose (but obvious) manual stuff than jump through 1000 hoops to kinda hack together an ORM that sorta works. I haven't touched a magical ORM since DataMapper ~4 or 5 years ago but that thing drove me nuts beyond the simple CRUD

ericgj commented 11 years ago

I wrote a plugin model-queries for dealing with this kind of issue among others, at least in terms of GETs, comments welcome. It's basically a thin layer on top of superagent in the context of your model class (Note it is tied to superagent so if/when abstracting the backend happens, it will have to change).

On the client side I haven't personally found a need for ORM association magic.

ianstormtaylor commented 11 years ago

in case it helps anyone, we're experimenting with model-memoize and using a flat approach, but still with the benefits of being able to warm the cache with json from the backend.

nw commented 11 years ago

I took a stab at a proof of concept. nw/model-nest Allows for basic nesting. It bubbles up change events to the root model as a 'nested.key.path'. This seems to play nice with nw/reactive-nest for referencing 'deep' properties in your model.

I agree with @visionmedia this should stay outside of the lib. The complexity grows quickly. There are so many edge cases that start to crop up. How do you handle saves, dirty, etc.

ianstormtaylor commented 11 years ago

yeah it's tricky. i think i agree that nesting should be outside the lib. trick is that keeping nesting outside of the lib basically means no nesting. because realistically its not going to play nicely with any other addons to model, so you either have to implement it all yourself, or not use other plugins.

either way i'm giving up on nesting anyways for now and i think i like the flat approach better.