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

Many Association #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

dalecaru
Copy link
Contributor

This is basically the same as referenced but returning the Ork::ResultSet instead of the first element.
Useful for one-to-many or many-to-many associations based on secondary indexes.

#
def many(name, model, reference = to_reference)
define_method name do
return [] if self.id.nil?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant self detected.

@dalecaru
Copy link
Contributor Author

I don't know if many is the right name, I was thinking in collection like in ohm, but here collection is a list of ids.

@emancu
Copy link
Owner

emancu commented Dec 19, 2014

We have collection but it returns the objects, not only the ids.

BTW remember this is not a relational DB, so there are a few differences on how we model our data.

On riak (1.4 at least) when you want to model a many_to_many or one_to_many relationship, you don't keep the FK on the child bucket (like you do on relational DBs), you must store a collection of ids in your bucket.
Basho team advice me about it and I changed ork's behaviour. If you review the history of collection method you will find that it was working as a relational DB.

@dalecaru
Copy link
Contributor Author

Yes, that's true. But the same would apply to referenced, right? It looks like a one-to-one modeling.

I would leave that desicion up to the user. You provide different alternatves with ork and he decides how to use them. For example links and link can be another options.

I believe that for small, medium size apps, modeling relationships with secondary indexes is just fine. When index2i was released in 2011, the very same Basho was saying this:

http://www.slideshare.net/rklophaus/querying-riak-just-got-easier-introducing-secondary-indices
http://basho.com/secondary-indexes-in-riak/

Maybe a small gem is the right place for this, like ork-hooks or the others.

@emancu
Copy link
Owner

emancu commented Jan 5, 2015

referenced it looks like a one-to-one but that is not an issue. It acts as the collection, and the id is persisted on the document itself so you are not breaking with the good practices.

About the links, the basho team suggested me to ignore them, because they don't work very well and they wanted to remove them in future releases.

I'm sorry but I don't believe that I should merge this into Ork, but of course you can make a ork-hook and I will be pleased to link it from the README.

@emancu
Copy link
Owner

emancu commented Jan 6, 2015

@damiancaruso do not close this PR yet. I will reconsider this PR, when I come back from vacations.

@dalecaru
Copy link
Contributor Author

When you say the id is persisted in the document itself you talk about reference not referenced, and that is perfectly fine. With referenced you are getting the referencing object through a index2i lookup, basically the same than the proposed many.

I would enable all the features using index2i when including a module as somebody might be using Ork with Bitcask backend. For example the current index method could be renamed to index2i in this module and the former rewrited to create indexes with riak objects.

I'm working on #map, #counter and #set, in which the latter would be a good replacement for collection as it is a CRDT built in Riak.

You're right about links, I think is deprecated in Riak 2.

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

Successfully merging this pull request may close these issues.

3 participants