I'm using django's model inheritance. Sorry I wasn't clear. So there's a
Word model and a Verb model.
class Word(models.Model):
# Word stuff
class Verb(Word):
# Verb-specific stuff
The way django handles this is to create a word table and a verb table. The
verb table has a reference to the word instance in the word table, plus any
other verb-specific information. I think the database is essentially the
same as this:
class Verb(models.Model):
word = models.ForeignKey('Word')
# Verb-specific stuff
But you're dealing with inheritance in python instead of composition.
On Thu, Jun 23, 2011 at 1:59 PM, Bill Freeman <ke1g...@gmail.com> wrote:
> I'm still confused about what you have (what form of inheritance you are
> using.
>
> In your database, are there both a Word table and a Verb table? Or is
> there just
> a (set of) Verb (and Noun and Adjective, etc.) table(s), derived from
> a non-Model
> Word class?
>
> If there's a Noun instance "record" and a Verb instance "record", do they
> share
> any data (such that if you change it in one it is changed in the
> other) or do they
> just have duplicate copies of some data?
>
> Bill
>
> On Thu, Jun 23, 2011 at 11:36 AM, Matthew Gardner <mj...@byu.edu> wrote:
> > Thanks, Bill, for your comments.
> > Shortly after I posted here I did a little more digging and found this
> > thread from six months ago that described exactly my problem:
> >
> http://groups.google.com/group/django-users/browse_thread/thread/9400999651577bc2/8cc4fe267128d6a3
> > That thread didn't seem to have a good solution, though...
> > As far as whether I should have done inheritance or composition, that's a
> > fair question that could have gone either way. But I chose inheritance a
> > while ago, as it seemed to make the most sense for what I am doing, and
> > that's the way the code is written. At several points in my code, I have
> > blocks that do things like this:
> > try:
> > verb = word.verb
> > # do verb-specific stuff
> > except Verb.DoesNotExist:
> > pass
> > I deal with a collection of words most of the time, and if they are also
> > verbs I add some additional stuff.
> > At this point, all I really want to do is add a row to the verb table
> that
> > contains the correct foreign key, without creating a new row in the word
> > table. And I don't want to write SQL to do it, though if I don't find
> > another solution, that's what I'm going to do, because it's fairly
> > straightforward to just do that. Also, I want to be able to delete just
> the
> > verb part, which is just deleting the row in the verb table and all
> > corresponding information (i.e., some other tables reference verb but not
> > word, so on deleting the verb row you want to delete the references to
> it).
> > And, now that I look at this, it seems that composition would have
> > simplified those two things, as django makes that nice and easy (with a
> > one-to-one field in Verb). If I can figure out a nice way to do it while
> > keeping inheritance, it would make my life easier, as I already have a
> bunch
> > of code written and databases that I don't want to repair that use
> > inheritance. But, given that it looks like composition would probably be
> > easier, maybe I should just take the hit and convert everything?
> Thoughts?
> > On Thu, Jun 23, 2011 at 10:09 AM, Bill Freeman <ke1g...@gmail.com>
> wrote:
> >>
> >> First, if, despite being related by inheritance, Word and Verb are
> >> separate models, they have separate tables. Then if you do create
> >> a Verb, the Word still exists, unless you delete it. Is that what you
> >> want? If both are to exist, were you hoping that a query for the
> >> same key would still find the Word, or do you want it to find the Verb.
> >> And how do you want to treat words (if text words they are) like
> "record",
> >> which is a noun (keep a record), a verb (record a performance) and an
> >> adjective (record crowd), at the very least. (Note that the
> pronunciation
> >> of the verb is different, if you were thinking of storing pronunciation
> >> info
> >> in the Word.)
> >>
> >> If you have separate models, you could certainly write the method that
> >> initializes a completely separate sub-class instance from the instance
> >> data of the super class instance. You could also do some magic using
> >> the field list available in the manager (which has the problem, IIRC,
> that
> >> it is not a public interface) to know which data to copy, though I'm of
> >> the
> >> explicit is better than implicit camp.
> >>
> >> So, I guess that I really don't know enough about your problem to
> >> suggest a detailed technique. I suspect that if it were me, I'd
> probably
> >> be using a foreign key reference from Verb to Word, rather than
> >> sub-classing.
> >>
> >> Bill
> >>
> >> On Wed, Jun 22, 2011 at 9:45 PM, Matt Gardner <drai...@gmail.com>
> wrote:
> >> > Hello all,
> >> >
> >> > I have a model hierarchy in my django app, and there is one very
> >> > important task that I do not know how to do. I have a bunch of
> >> > instances of the superclass (Word is the model name), and on input
> >> > from a user I want to create a subclass instance (Verb) from that
> >> > superclass instance. For example, I might have code like this:
> >> >
> >> >>>> word = Word.objects.get(pk=[input from user])
> >> >>>> verb = Verb.createFromSuperclassInstance(word)
> >> >>>> verb.save()
> >> >
> >> > The only problem is that I know of no such
> >> > "createFromSuperclassInstance" method, nor where to look for it. I do
> >> > know how to do this through the database itself (just add a row to the
> >> > verb table with the correct foreign key), but I was hoping django
> >> > would provide some nice way to do it without me having to explicitly
> >> > write SQL. The Verb class's __init__ method creates a new Word
> >> > instance, so that doesn't work, unless there's a way to use it that I
> >> > don't know about.
> >> >
> >> > Any help?
> >> >
> >> > Thanks,
> >> > Matt
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Django users" group.
> >> > To post to this group, send email to django-users@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > django-users+unsubscr...@googlegroups.com.
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/django-users?hl=en.
> >> >
> >> >
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Django users" group.
> >> To post to this group, send email to django-users@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> django-users+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/django-users?hl=en.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/django-users?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
