No Model Inheritance in Magic-Removal?
daniel...@gmail.com
Please tell me it isn't so...
I cannot BELIEVE that I spent several hours yesterday migrating my
project to the "Magic-Removal branch", now that it's been merged to
trunk and adopted by so many people, only to discover after my stuff
breaks and I do some reading up in the newsgroup, that model
inheritance (which I use quite a lot of) is not supported AT ALL in the
MR branch.
I read and followed these docs:
http://code.djangoproject.com/wiki/MagicRemovalCheatSheet
http://code.djangoproject.com/wiki/RemovingTheMagic
Both of these don't even MENTION model inheritance (I just checked,
doing a fulltext search). RemovingTheMagic: "This document explains all
changes." -- Um, no. It appears it doesn't.
My reason for migrating to the mr branch? I want to launch soon and I
didn't really want to launch with a soon-to-be-obsolete codebase and
database schema, forcing me to spend even more effort in migrating data
later on, when many users (hopefully!) have entered lots of data into
my portal.
Please tell me I'm missing something.
Please tell me inheritance is working fine, it's just some other bug
that's keeping my fields from actually showing up in the subclasses and
causing exceptions of the kind "Cannot resolve keyword 'submissiontype'
into field".
Please tell me I don't have to throw away a couple of hours of work and
go back to the previous version, forcing me to do the changes AGAIN at
a later point in time (PLUS forcing me to spend effort on database
migration).
Arrrrrgggggghhhhhh!!!
Sorry. Had to vent. Anyway. Please tell me it isn't so.
Daniel
Douglas Campos
....
Mark Striebeck
(i just subscribed to this list a few days ago but have the same issue as daniel)
MarkS
daniel...@gmail.com
And what good is THAT supposed to do?
As opposed to, e.g., maybe including this in the list of
backwards-incompatible incompatible changes
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges or on
the http://code.djangoproject.com/wiki/RemovingTheMagic page or in the
http://code.djangoproject.com/wiki/MagicRemovalCheatSheet ?
Do you expect everybody to religiously follow and read up on the
dicussions in the newsgroup?
Now that I knew what I was looking for, I found a note in this page:
http://code.djangoproject.com/wiki/WikiStart : "[...] so if you need
model subclassing stick to one of the older stable releases". Model
subclassing is even still covered in the current docs, at
http://www.djangoproject.com/documentation/models/subclassing/ --
again: now that I know what I'm looking for, I see that a comment about
this not working in M-R has been added to the very end of the page.
Dan.
James Bennett
> http://code.djangoproject.com/wiki/WikiStart : "[...] so if you need
> model subclassing stick to one of the older stable releases".
"or use workarounds like one-to-one relationships."
It's not the prettiest thing in the world, but it'll work for now and
it might be easier to migrate than bringing an entire app up to
current trunk from an older release once subclassing is hashed out.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Don Arbow
> what has been discussed for two months? that model inheritance will
> not
> longer be supported? or that there is a alternate way to support the
> concept?
What was discussed is that model inheritance is not yet ready for
prime time. Some folks are working on it.
Don
Russell Blau
news:21787a9f0605301106ye3...@mail.gmail.com...
>
> On 5/30/06, daniel...@gmail.com <daniel...@gmail.com> wrote:
> > Now that I knew what I was looking for, I found a note in this page:
> > http://code.djangoproject.com/wiki/WikiStart : "[...] so if you need
> > model subclassing stick to one of the older stable releases".
>
> "or use workarounds like one-to-one relationships."
>
> It's not the prettiest thing in the world, but it'll work for now and
> it might be easier to migrate than bringing an entire app up to
> current trunk from an older release once subclassing is hashed out.
"it'll work for now..." BUT, as has been discussed here over the past few
weeks, it is not guaranteed to work for the future -- there is a warning in
the new docs *not* to use OneToOneField because it's expected to change
soon.
James Bennett
> "it'll work for now..." BUT, as has been discussed here over the past few
> weeks, it is not guaranteed to work for the future -- there is a warning in
> the new docs *not* to use OneToOneField because it's expected to change
> soon.
That warning, I believe, has to do with plans to deprecate one-to-one
relations once model subclassing works. One-to-one relationships
between models are basically a really verbose type of subclassing.
daniel...@gmail.com
heart and I really can't bring myself to replace inheritance with
one-to-one relations or delegates or copy/paste.
*sigh* - I'll just have to do it all again when there's a stable
release >= 0.95 which supports inheritance.
It's really a pity, because in the course of porting the app I found I
really like the new database API, with things like "order_by" as a
function and [:5] instead of "limit=5" feeling much more natural to me.
Daniel.
gabor
> On 5/30/06, Russell Blau <russ...@hotmail.com> wrote:
>> "it'll work for now..." BUT, as has been discussed here over the past few
>> weeks, it is not guaranteed to work for the future -- there is a warning in
>> the new docs *not* to use OneToOneField because it's expected to change
>> soon.
>
> That warning, I believe, has to do with plans to deprecate one-to-one
> relations once model subclassing works. One-to-one relationships
> between models are basically a really verbose type of subclassing.
>
imho one-to-one "subclassing" is just one of the possibilities as
discussed at http://code.djangoproject.com/wiki/ModelInheritance.
for example, my situation:
i have a lot of models, and there are some fields that have to be there
for every model: creation_date, who_created_it, score, whatever. and i
hate to cut&paste it into every model. so i'd prefer to do it with
inheritance. but i do not want to spend a join everytime i look up the
creation_date. i would rather have it collapsed into one table.
probably the question is:
do you expect to use instances of the parent class? if yes, then
probably the join-approach is better, if not, then probably the
collapse-into-one-table approach is more suitable.
gabor
Malcolm Tredinnick
A concrete note about the status of model inheritance...
I haven't really been advertising this, because I'm not sure when it
will be ready, but I am working on making model inheritance work at the
moment. It will be a week or two yet before I have anything to send in
to the developer's list, because I am a bit busy in my Real Life at the
moment -- like everybody else, it's just volunteer (but fun) work for
me. It may take a little longer, depending upon how much time I have (I
had hoped to have something a week ago, but other events interfered). I
can't promise anything more solid than that, I'm sorry.
This work is not completely trivial and there are a lot of curly corner
cases, many of which are discussed in the Wiki page, some of which
aren't. So please bear with us. Once I have the patch working, I will
send it to the dev list, people with throw fruit at me and then we will
try to work out the problems. The ranting doesn't help a lot.
Thanks,
Malcolm
daniel...@gmail.com
that sounds great! I'm really looking forward to that.
When it's ready, I'll try and contribute to the discussion and be a bit
more productive, instead of just 'ranting'. :-)
Daniel