How do I change the column which is used to build the path? about ancestry

[stefankroes]

This is not possible right now and would require a lot of changes. Can you provide a use case?

[krisleech]

I guess the one that springs to mind is if you aren't using Rails' id field as you primary key, maybe you are using a permalink or some other kind of string, e.g a hash.

[stefankroes]

You should always use the ID column as you primary key in Rails. If you also want to save permalink slugs that's just fine! Just use something like this to build the path:

def permalink; path.map(&:slug).join('/'); end

You should not use the content of the ancestry column directly.

[krisleech]

I would agree that in most circumstances its wise to use the ID column as your primary key, but sometimes there are good reasons for not using it, for example if you have a natural unique key (e.g ISBN number, Invoice Number, MAC address) or your using a GUID to aid data migration/sync between distributed systems.

[stefankroes]

Even in those cases; please still just use an id column as well. What if we run out of ISBN numbers and the scheme changes or we start reusing them? What if your application that uses ISBN numbers needs to be extended to track unpublished books?

Also database are more efficient at looking up records with integer id columns; ISBN numbers, invoice numbers and mac addresses all contain special characters (:-/) which requires you to save them as a string. Same goes for generating ids and integrity contraints like uniqueness and foreign keys.

There is really no reason to just have both: an internal id and an external id like a isbn, mac address etc.

[krisleech]

I think natural versus artificial keys is a moot point. The choice is dependent on your data and stance on such things, there is no right/wrong. Because the Rails way is to have a artificial key for everything I understand this is an edge case, 99% of people will be happy with using the id, in fact more than likely that's all they'll have.

But it is perfectly valid to not want to use an artificial key. Merging data is hellish with auto-inc id's since they are not unique like UUID's, again not something 99% of Rails developers need to worry about.