On Wed, 2007-10-10 at 22:12 -0700, [EMAIL PROTECTED] wrote: > Hello, > > I am following the discussion in the ticket > http://code.djangoproject.com/ticket/2145, > and I think its not correct place to discuss theoretical things in > ticket, instead discussion should be moved to a Groups (to either > Users or Developers. I post to Developers because the nature of ticket > is about developing Django itself). > > I would like to ask: are there any practical way to extend your models > (DRY) ? What exactly is going on: I have build one e-commerce store > with Django. Then, I build 2nd, and 3rd and found that many parts are > similar, so there must be way to maintain some "core" part between > different installations, and write "custom" part for every > different customer needs. > > May be I miss something, but the only obvious way to do that with > Django is to use OneToOne relationships. > So far, we had great success with this approach and actively actively > using 1:1 fields in our project (http://djwarehouse.org). > > We understand the limitations of ORM and theoretical and practical > difficulties of implementing model inheritance. > > But if we go back to real life requirements, we also need would like > to write reliable, easy to use and extend software, and we need it > now, not some years later, as some suggest in ticket system. Exactly, > what we need is: > > * keep general code common for all (Dont Repeat Yourself). > Practically, we maintain common code in one > model, and custom code & data in tied 1:1 model. > > * maintain good performance. AFIK it is only possible by using 1:1 OR > model inheretance.
Since a OneToOneField looks exactly the same at the database level as a ForeignKey with unique=True, you can use that as well. In both cases, one table contains a field that refers to a field in a remote table. There is no difference in the efficiency stakes as far as portable SQL goes. For some reason, this seems to be a big hangup for people, but look at the SQL representation. > While MI is not started at al (?)l, OneToOne works excellently. > > So far only 5 patches are needed, some are quick & ugly, but I did not > experienced any problems > with them: http://djwarehouse.org/browser/djWarehouse/trunk/docs/patches > during last year. They all appear to be copies of the tickets we have in Trac, so they'll be considered and updated in due course. A number of them are against manipulators (deprecated) and existing admin (obsolete), so they are much less likely to go in. But things like necessary patches against fields/related.py will go in at some point when one of the maintainers sits down to work on this area. > The only problem I see is the approach how things get fixed in trunk. > Most of those pathes & ideas > are refused by 2 reasons: > > * OneToOne fields will be soon depricated; I keep hearing about this. All I've read is "the semantics of OneToOneFields will be changing soon" (in models.txt). Don't read more into this than there is. I'm not saying anything definitive -- I am saying that I know as little as you do about it, which isn't much. > * There are no need to fix Django /admin since newforms-admin is > coming. > > Both things could be true, and some day they will became reality. But > current reality is different, neither model inheritance is ready, and > neither newforms-admin is functional yet. The guiding principle is that we don't spend any real amounts of time working on things that are already slated for removal or replacement. We are pretty consistent in that. We want to have model inheritance and we are writing newforms-admin. So we (core devs and a lot of other people) aren't spending time on workarounds -- instead focusing on driving towards those goals (along with our 570 other high priority items). Yes, it's frustrating that it hasn't been done yet. I absolutely apologise for the delay in some of these features and I sympathise with the problems the delay causes. But hoping for "official temporary replacements" is not going to bear a lot of fruit, I'm afraid. > > I see Adrian added ticket http://code.djangoproject.com/ticket/24 > which addresses same issue, but 10/19/05 rjwittams said: > > > This will happen "for free" when OneToOne? is moved to subclassing, as the > > admin page would be generated > > from the dynamic type of the object. > > And ticket was closed as: wontfix. > > This is common for all our tickets we maintain in this area. > > So, the question is: are there any other practical way to do the > things I explained easy, without using OneToOne fields? ForeignKey(unique=True) Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
