Allow customization of column for ancestry relationships (using non-primary key)

[a5-stable]

Greetings,

The ancestry gem currently assumes that the parent-child relationship is managed using the primary key.
However, there are certain cases where a different unique column needs to be used to manage the relationship when we use other columns as a identifier.

This is how it would behave;

class Category
   has_ancestry ancestry_identifier_column: :another_identifier_column
end

root = Category.create!(another_identifier_column: 100)
node = Category.new(another_identifier_column: 200)
node.ancestor_ids = [root.another_identifier_column]
node.save!

node.ancestry
#=> 100

Some gems allow customizing the column used for managing parent-child relationships. For instance, the awesome_nested_set gem provides a primary_column option that enables users to specify which column should be used as the parent reference (parent_id).

I am currently working on a PR to add this feature to ancestry, as I need it for my product. I’d be happy to submit it if you find this approach acceptable.

[kbrock]

Hello @a5-stable

This is a lot of change. I'm hesitant to incorporate a change like this.
I had looked into implementing a mechanism to allow people to store a custom path, but that would be used for things like breadcrumbs and not for the primary id.

[a5-stable]

@kbrock
Thank you for your feedback!
I understand that this may feel like a big change, but the change itself can actually be straightforward.
I have drafted a sample PR that aims to abstract the id or primary_key specification as a starting point.
I would appreciate it if you could take a look when you have a moment.
#698

After this, the next steps for this feature would be:

• Introduce an option to specify a custom ancestry_identifier_column
• Add ancestry_identifier_column_key_format

[kbrock]

this looks like it will add a lot of send/read_attribute changes. and making the code less readable. It is possible that it will find some edge cases that don't work for custom ids.

I do wonder if the id field breaks for a different primary_key - but we run the whole test suite with that use case and it passes. (not saying it won't break, just saying we do make an honest try)

For some reason, those two initiatives feel like they overlap. Feels like enabling a different primary_key would be similar to enabling a different key all together.

Again, if you want to get this feature in, we need to find a way that this is not a whole bunch of extra with added send and read_attribute calls, and simple variable names that are now more complex.

[a5-stable]

Thanks, I responded here, including points about code readability and the API.