Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating documents in relations #12

Closed
cie opened this issue Oct 16, 2013 · 5 comments
Closed

Creating documents in relations #12

cie opened this issue Oct 16, 2013 · 5 comments

Comments

@cie
Copy link

cie commented Oct 16, 2013

Hi! How about something like

band.members.create(name: "Fletch")

? It looks better than

Member.create band_id: band.id, name: "Fletch"
@kaptron
Copy link
Contributor

kaptron commented Oct 18, 2013

Would be great, agreed. See #8, band.members is not really an object manager, it's just an array (in the case of embedded models) or a function that performs the appropriate find (in the case of related models). I welcome any pull requests that would implement this feature...

@cie
Copy link
Author

cie commented Oct 18, 2013

Ok, thanks. I don't yet know if I'll implement it or not. But I think if somebody implements it, they should consider also other Mogoid methods besides create (like push, new, where, find, delete) to make it more POLA.

@sslotsky
Copy link
Contributor

Taking a look at this, it looks feasible in some cases but not others.

For example we can do this when resolving a has_many because we have access to the classname:

      @[relation] = do(relation, selector, class_name) ->
        (mod_selector = {}, options = {}) ->
          # first consider any passed in selector options
          mod_selector = _.extend mod_selector, selector
          # e.g. where {user_id: @id}
          if global[class_name]
            models = global[class_name].where mod_selector, options
            return Relation.new class_name, models...

The Relation class could then have your create method as well as others. But this is more difficult to do from the @where method because we don't have access to the actual class name from this location, from what I'm able to tell.

@sslotsky
Copy link
Contributor

I retract my previous statement. I'll have a pull request shortly.

@kaptron
Copy link
Contributor

kaptron commented May 1, 2014

see #16

@kaptron kaptron closed this as completed May 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants