Re: Easier to use natural keys.

[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.

On Sunday, December 21, 2014 9:31:22 AM UTC-5, Torsten Bronger wrote:
>
> 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 BrongerJabber ID: torsten...@jabber.rwth-aachen.de 
>  
>   or http://bronger-jmp.appspot.com 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd678911-70e8-41be-b5d8-925c6992f551%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easier to use natural keys.

[Brian Faherty]

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

On Sunday, December 21, 2014 6:50:22 PM UTC-5, Russell Keith-Magee wrote:
>
>
> On Sun, Dec 21, 2014 at 10:33 PM, Josh Smeaton  > 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 %-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72b62243-b444-4623-8e32-bfc4c88470de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8a17ce37-0ce4-4648-bcc6-8d6cfe35e4e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.