Gary Wilson wrote:

> This is a tricky way around django.db.models.base.Model.__init__'s current
> enforcement of the foreign key field (without the _id) wanting an instance,
> but shouldn't be needed if we implement the above (meaning create() would act
> like get() in that you could pass either an int, a str, or a model instance to
> the foreign key field).

Hmmm, I'd almost say this was the best solution; ie, losing the magic
fkname_id notation altogether in favour of making it consistent (in a
gradual phased manner of course!).

The only problem here though, we'd need to continue the trend, by
changing model.__set__ so that by setting instance.fkname = 47 it'd
lazy load instance.fkname as a proper model instance, rather than an
int (or str/date/time etc).

Great, but then how do I get the fkname_id int without having to hit
the database? Looks like we're straight back to the drawing board with
the magic fkname_id notation again!


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to