Model inheritance extended.

[Jonathan Slenders]

Hi everyone,

This may be interesting to some of you. I created a small library for inheritance of a set of models.

It's best to go quickly through the Readme on the site below.

We felt a need for this, but I'm wondering whether some kind of inheritance like this has been discussed before. And whether, if useful, this would make a candidate for django.db.

https://github.com/citylive/django-model-blueprint

Cheers,

Jonathan

[Anssi Kääriäinen]

On 24 syys, 16:55, Jonathan Slenders <jonathan.slend...@gmail.com>
wrote:

> This may be interesting to some of you. I created a small library for

> inheritance of *a set of* models.

> It's best to go quickly through the Readme on the site below.
>
> We felt a need for this, but I'm wondering whether some kind of inheritance
> like this has been discussed before. And whether, if useful, this would
> make a candidate for django.db.
>
> https://github.com/citylive/django-model-blueprint

Looks interesting! It is nice to see how little code you needed to
implement this. Inheriting a system of models should be useful in some
special circumstances. I know I have missed that feature at least
once...

In general, we try to have stuff live outside of core as much as
possible. This feature doesn't seem to be something everybody needs,
and doing this outside of core seems to be possible already.

If this turns out to be really useful, then that might be a reason to
move this into core.

Are there things you would like to do but aren't able to because this
isn't in core? Is there something we could change in core to make
maintaining of this easier?

- Anssi

[Dan Fairs]

On 24 syys, 16:55, Jonathan Slenders <jonathan.slend...@gmail.com>
wrote:

This may be interesting to some of you. I created a small library for
inheritance of *a set of* models.
It's best to go quickly through the Readme on the site below.

We felt a need for this, but I'm wondering whether some kind of inheritance
like this has been discussed before. And whether, if useful, this would
make a candidate for django.db.

https://github.com/citylive/django-model-blueprint

Looks interesting! It is nice to see how little code you needed to
implement this. Inheriting a system of models should be useful in some
special circumstances. I know I have missed that feature at least
once...

fwiw, I've implemented something like this in another project, as well. It did more stuff (model partitioning for large data volumes, handling the case of deriving from generated base classes, shared models between 'blueprints'), but the core of yours looks pretty neat.

Cheers,

Dan

--
Dan Fairs | dan....@gmail.com | @danfairs | www.fezconsulting.com

[Calvin Spealman]

This is some nice looking black magic. That is going into my toolbag
and I'm looking forward to a use case to pull it out for.

> Cheers,
> Jonathan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/WIkRQuzDRCsJ.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.



--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

[Daniel Sokolowski]

Hi Jonathan, I am undecided on this one, when I first looked at it I thought it was a great idea but now I feel it would be more problematic to read and traverse and update such code due to the ModelFactory > MyModelFactory > MyModels logic flow. It feels a lot like using class based views – exciting at first but quickly the paradigm became complicated to understand and traverse when used beyond the base examples (at least in my case and until I understood it well enough). It also seems the current abstract model mechanism can do everything a model library can minus the model prefixing and the model grouping; that though I would just tackle using a naming convention, i.e. SimpleLibraryBook, ExtendedLibraryBook, with a BaseBook abstract class.

 

Also where would the code live model_libraries.py ? I think explicit is better then DRY in this situation. This my opinion and as such can change - thank you for considering it.

--

Daniel Sokolowski
http://webdesign.danols.com/

[Alex Ogier]

On Mon, Sep 24, 2012 at 12:33 PM, Daniel Sokolowski <daniel.s...@klinsight.com> wrote:

It also seems the current abstract model mechanism can do everything a model library can minus the model prefixing and the model grouping; that though I would just tackle using a naming convention, i.e. SimpleLibraryBook, ExtendedLibraryBook, with a BaseBook abstract class.

There's a big thing you cannot do without grouping models: you can't have an abstract base class relate to another abstract base class. Django's foreign key mechanism doesn't know how to relate to a to-be-instantiated concrete class. This is more or less the same problem that is solved by Russell's User model switching code: you want libraries to relate to the User model, but you also want application writers to subclass the User model. Russell's solution is bottom-up: you swap out the User model at runtime, and refer to it indirectly everywhere. Jonathan's solution is top down: you instantiate all your model classes together, resolving references at load time. Jonathan's solution is nice because it lets you instantiate multiple copies of the same base. Russell's is nice because it doesn't require invasive architectural changes, such as moving all your base classes to a single factory.

I like this solution. I don't think it strictly has to be in core though: if I wanted to distribute a blueprint model, I can just depend on django-model-blueprint without even requiring any changes to INSTALLED_APPS, which means the only benefit to being in core is canonicalizing the pattern.

Best,

Alex Ogier

[Andrew Ingram]

On 25 September 2012 17:45, Alex Ogier <alex....@gmail.com> wrote:

There's a big thing you cannot do without grouping models: you can't have an abstract base class relate to another abstract base class. Django's foreign key mechanism doesn't know how to relate to a to-be-instantiated concrete class.

Not entirely true, the foreign key can use a string 'app.Model', we've used this mechanism quite extensively in Oscar (an e-commerce) platform to allow overriding or extending of any model without having to change the code for other models. That said, we have to do some quite ugly tricks to get this working properly.  I'm intrigued by this ModelFactory approach because it can potentially remove some of our hacks, but I'm not overly keen on adopting an new idiom that isn't widely accepted as a good approach. So I'm following this discussion with interest.

- Andy Ingram