how practically to extend your models?
alex.v...@gmail.com
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.
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.
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;
* 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.
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?
Let me explain on example of that I need. Typical e-commerce store
have only Product title, description, price and rank fields. Custom
commerce store which sells books, have also ISBN code, authors,
publisher and other fields.
The only reliable and fast way would be to use OneToOne field to
connect custom attributes to main model.
Are people using different approaches? I can't believe that no-one is
writing appplications, which is being reused in some way. Most
probably, me, and some others are either using Django in some wrong
way, and miss something, or Django is not made to the purpose of code
reuse.
Please advice.
Best Regards,
Alex
Ilya Semenov
admit you have the most sane and comprehensive opinion I ever heard on
the 1-to-1 problem. Completely agreed on the every point.. And no, I
don't see any other way on practically extending the models for
natural and DRYish reusing the codebase.
Alas, I doubt we can do much about that. The maintainers don't seem to
care about 1-to-1. There's nothing wrong with them; that just happens
that they're not interested - there's plenty of other unresolved
issues with Django.
If we want to push the patches to trunk, first we need to do is to
examine bug reports on every patch, and either fix the patch, or prove
that the problem does not actually exist.
Malcolm Tredinnick
> I'm one of those who participated in ticket #2145 discussion. I must
> admit you have the most sane and comprehensive opinion I ever heard on
> the 1-to-1 problem. Completely agreed on the every point.. And no, I
> don't see any other way on practically extending the models for
> natural and DRYish reusing the codebase.
>
> Alas, I doubt we can do much about that. The maintainers don't seem to
> care about 1-to-1.
Nonsense! You and a few other people seem to have taken this view, but
it's totally incorrect. Understand the very real difference between
"haven't completed the work yet" and "are not interested". It's a matter
or prioritisation.
What we have said is that the one-to-one API might change at some point
and that's almost certainly true. For example, to let multiple
inheritance (e.g. mixins) work, we need OneToOneField to not just be
restricted to being the primary key on the model.
The fact that we choose not to participate in discussion that has varied
very far from the point in tickets like #2145 doesn't mean we're not
interested. It means we're working on other things *at the moment* and
not being distracted by having to step in and correct every little error
that floats around in comments.
Malcolm
Marty Alchin
relationships have problems" to "Django is not made to the purpose of
code reuse". There are many ways to reuse code in Django, without
having anything to do with one-to-one relationships, or even model
relationships at all. Things like generic views, template inheritance,
includable urlconfs and the like.
I can appreciate your frustration, but your points will be much better
received if your criticisms are relevant to the discussion.
-Gul
Malcolm Tredinnick
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
alex.v...@gmail.com
On Oct 11, 4:09 pm, "Marty Alchin" <gulop...@gamemusic.org> wrote:
> Also, for what it's worth, it's quite a leap to go from "one-to-one
> relationships have problems" to "Django is not made to the purpose of
> code reuse".
> There are many ways to reuse code in Django, without
> having anything to do with one-to-one relationships, or even model
> relationships at all. Things like generic views, template inheritance,
> includable urlconfs and the like.
Agree, if you re-read my mail, I do not complain, I really appreciate
the work
core developers do, and in fact I love Django framework. What I am
curios
about if I am doing things the right way.
When I asked about Django and code reuse, I am mostly interested in
the patterns
which make the *things I do* possible some other way. Exactly, I found
it Django being
excellent in creating sites fast, but pretty difficult to reuse same
models code/data between different projects.
> I can appreciate your frustration, but your points will be much better
> received if your criticisms are relevant to the discussion.
Sorry, I did not meant this. And I am not frustrated. I do understand
there are many high priority tasks which are more important then this
one.
And in fact, Open Source is about "fix it yourself". Probably instead
of talking here, I have
to spend my time on hacking the problems we discuss :-)
With my original mail, I only tried to:
1. Make sure developers know that problem exist (some know, but in
some cases bugs are/were closed)
2. Try to understand if I am going in right direction. Should we fix
1:1 or should we try to look for different
approach?
What actually really bothers me, is why many 1:1 bugs are closed as
"wontfix". This really needs
to be discussed, and I once raised such discussion.
IMO, closing bugs as wonfix moves developers attention to other
things, while we still do have the problems
with trunk. Yes, its good to believe that some day problems with 1:1
will go away with newforms-admin,
or with model inheritance.
But in my opinion, until thing is fixed, do not close bug. May be some
smart developer look and provide
good design solution. If bugs are closed, nobody will look at them.
So, IMO if there are bug, and if this bug can be reproduced in current
trunk, it issue must stay open.
And it must stay open until we either fix it, or it became obsolete.
Tai Lee
level, but OneToOneField does have a couple of niceties attached to it
like adding the related object as an attribute to the model containing
the OneToOneField. If those could be re-added to ForeignKey fields
with unique=True, that would be a good start ;)
alex.v...@gmail.com
On Oct 11, 4:20 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
>
> ForeignKey(unique=True)
>
I will try it this way & hope it works exactly as I need it to.
Thank you for reading carefully my Email :-)
My main point was not to criticize Django but to understand if there
are other ways
to do things I need to do.
> 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).
Absolutely agree with that, and I understand it well. The only
question
which I also raised is about trac/tickets. IMO, if issue is about
current trunk,
and if its not fixed yet, closing it as 'wontfix'... Hm. May be we
should have
specific state for: "to be fixed in futurre".
Malcolm Tredinnick
That sort of thing is one of the reasons I'm not actively agitating for
OneToOneField to disappear at the Python level. It does have its uses. I
was trying to stem the recent tide of comments in a few places that
there is some great difference between 1-1 and 1-n with a unique
constraint.
Regards,
Malcolm
AJ
ForeignKey(unique=True) and the few reasons to use a OneToOneField
would obviate a lot of this discussion and perhaps save folk time
which can be used to address some of the 570 outstanding bugs. ;)
I'd offer to write them but am not familiar with the process (yet!)
nor is my writing style particular suited to manuals. :(
AJ
[ Relatively new to Django but already hooked! Thanks guys!!! :))) ]
Malcolm Tredinnick
On Mon, 2007-11-12 at 12:41 -0800, AJ wrote:
> A couple of paragraphs in the documentation highlighting
> ForeignKey(unique=True) and the few reasons to use a OneToOneField
> would obviate a lot of this discussion and perhaps save folk time
> which can be used to address some of the 570 outstanding bugs. ;)
If it was that simple we would have said it only needed documentation
(or perhaps written it). However changes are needed to OneToOneField,
for example.
Malcolm
--
How many of you believe in telekinesis? Raise my hand...
http://www.pointy-stick.com/blog/
AJ
On Nov 12, 10:15 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> > A couple of paragraphs in the documentation highlighting
> (or perhaps written it). However changes are needed to OneToOneField,
> for example.
I have spent several hours investigating the issues I had with 1-2-1s
and the solutions to those issues as have many other people. A couple
of paragraphs in the documentation would definitely have helped me but
more importantly they would have saved save you and your team the time
you have spent on this ticket and quite possibly on a few of the
aforementioned 'wontfix' bugs.
Anyway - I am not in the business of wasting my time nor yours and I
don't believe I can make my point any better than I already so enough
said. Feel free to contact me directly if you feel I can add further
to the discussion.
Regards,
AJ