Easier to use natural keys.

[Brian Faherty]

Hey Folks,

  Teams I have been on in the past have used natural keys extensively. As a result many people have complained about the current way to implement them. Not only do you have to implement two methods that are the reverse of each other in a compatible way, but you also need to remember to attach the manager which you created to the model. None of these steps are hard, but some are easy to typo, and when a typo is made error messages can be sort of confusing to debug. The best example is if the manager is missing the get_by_natural_key method, is it really missing on the manager or is the wrong manager on the model.

  The solution I propose is a meta field on the model that allows you to set natural keys there. If done in a way where it was backwards compatible it could be added without breaking existing functionality. I already have code for it and put in a ticket. After some extensive feedback from freakboy3742 (thank you btw), timgraham recommended that I bring this up on the developers mailing list if I feel strongly about it. So here I am. I am willing to continue work on this code if someone proposes a change that they think would be necessary to accept this idea.

Brian

[Torsten Bronger]

Hallöchen!

Brian Faherty writes:

> [...]

>
> The solution I propose is a meta field on the model that allows
> you to set natural keys there.

FWIW, we currently have attached to our models

class MyMeta:
identifying_field = "number"

as a means to set something like "poor man's primary key". Thus, I
think we would benefit from such a setting. (By the way, we did use
natural keys first -- but it was slower, didn't allow for
introspection, and resulted in uglier code.) I could explain our
use case if asked for.

Django discourages to set explicit primary keys. In case of MT
inheritance, it didn't even work for us (maybe we were too stupid).
There is nothing wrong with that. But then, it would be helpful to
have this poor man's PK instead.

Tschö,
Torsten.

--
Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com

[Josh Smeaton]

Would you mind linking to the ticket you're talking about? Will encourage more people to participate if they don't have to search Trac for it ;)

Josh

[Russell Keith-Magee]

On Sun, Dec 21, 2014 at 10:33 PM, Josh Smeaton <josh.s...@gmail.com> wrote:

Would you mind linking to the ticket you're talking about? Will encourage more people to participate if they don't have to search Trac for it ;)

He did - as an inline link:

https://code.djangoproject.com/ticket/23780

Yours,

Russ Magee %-)

[Josh Smeaton]

So he did, Flux must have killed link colours for me.

Sorry folks!

[Brian Faherty]

Thanks for re-linking it. I maybe should not have done it as inline. 

[Brian Faherty]

I think we use a similar idea for serializing and communicating between distributed systems.  On our rest serializes, we set a property called lookup_fields. However, if it was standard to use a metadata property from the model, it might allow for some third party libraries to standardize.