-
Notifications
You must be signed in to change notification settings - Fork 239
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
find_or_create_by attributes not working #61
Comments
So your "name" column isn't unique? I'm hesitant to use a conditions hash, because multiple rows may match Seems like for your case, unless I'm misunderstanding (which is likely),
Matthew
|
Nope, name is not unique. It's actually not even unique to a client, since you could potentially have a hierarchy that goes 'All'->'Northeast'->'NYC'->'North' and another that goes 'All'->'Canada'->'Northeast'->'Halifax'->'North'...you get the idea. To make matters more confusing each client has multiple roots: TagDefinitions include both the hierarchical case I've described (a regional hierarchy of store locations, essentially), but can also include flat 'filter' tags such as brand, store type, etc. that, being flat, come up as roots. You're right though - I can pop the first element off the list for the name of the root node and find_or_create_by given the name, client name, context, and level (the root node isn't guaranteed to be there If I'm on-boarding a new client), and then find_or_create_by_path the remainder of the list from the root node. Thanks a lot for that. That said, I suppose the confusing part for me is that the create honors the conditions hash, but the find doesn't, which I didn't expect - in the example in the docs, you have:
If I'm not mistaken, let's assume you have another tag_type of "Picture", which also has a "home" tag - depending on how your DB orders it, |
You convinced me—thanks for your help. https://travis-ci.org/mceachen/closure_tree/builds/7928772 is building 2760c03 |
This will drop in v4.2.0, being released shortly. |
Me again, with another weird edge case issue:
In my app, our hierarchical tags are scoped to a particular client and we indicate this with a 'client_name' field in our TagDefinition object.
I'm calling find_or_create_by_path thusly
TagDefinition.find_or_create_by_path(hierarchies, {'client_name' => client_name, 'context' => TagDefinition::HIERARCHY_CONTEXT})
where 'hierarchies' is an array of tag_definition names. The problem is this - every single one of our clients has a root tag called "All". When I run the above snippet for a hierarchies value of ['All','North','South'] for a client_name of 'aperture_science', closure tree happily finds the root tag 'All' - for another client, 'acme', and then creates all the other tags with the incorrect tag as the root.
The problem is this:
In both the class and instance methods of find_or_create_by_path, you accept a hash of attributes that get passed to active record. This is all groovy, except that the hash of attributes is only honored in the insert/update, NOT in the where clause.
I updated my fork https://github.com/juddblair/closure_tree with a quick and dirty fix (merged in the attributes hash before the where clause) and ran it against our app, seemed to fix the problem.
The text was updated successfully, but these errors were encountered: