Re: Model inheritance extended.

2012-09-25 Thread Andrew Ingram 
On 25 September 2012 17:45, Alex Ogier  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

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model inheritance extended.

2012-09-25 Thread Alex Ogier 
On Mon, Sep 24, 2012 at 12:33 PM, Daniel Sokolowski <
daniel.sokolow...@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

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model inheritance extended.

2012-09-25 Thread 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. 

From: Jonathan Slenders 
Sent: Monday, September 24, 2012 9:55 AM
To: django-developers@googlegroups.com 
Subject: Model inheritance extended.

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
-- 

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

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model inheritance extended.

2012-09-25 Thread Calvin Spealman 
On Mon, Sep 24, 2012 at 9:55 AM, Jonathan Slenders
 wrote:
> 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

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-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@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

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model inheritance extended.

2012-09-25 Thread Dan Fairs 
> On 24 syys, 16:55, Jonathan Slenders 
> 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.fa...@gmail.com | @danfairs | www.fezconsulting.com

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model inheritance extended.

2012-09-25 Thread Anssi Kääriäinen 
On 24 syys, 16:55, Jonathan Slenders 
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

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Model inheritance extended.

2012-09-24 Thread 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

-- 
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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.