On Wednesday, June 11, 2014 2:16:06 AM UTC+2, Craig de Stigter wrote:
>
> I reserve judgment on whether STI should be included in core. It works
> fine in a third-party app. Some better support for it in core would be
> helpful, since currently I'm relying on some unsupported stuff that the
>
Late reply I know but I see a lot of FUD in this thread and I want to try
and clear it up.
> in the general case, STI means you have to make almost all the fields in
your model NULLable. You lose any semblance of having an actual database
schema, and end up writing a whole lot of code to re-im
On 6 juin 2014, at 09:42, Thomas Güttler wrote:
> I think it is a "not invented here" syndrome: Ruby on Rails did it before.
> That's
> a reason to do it different.
The reason is more simple.
Rails was designed around MySQL, a database with a rather casual relationship
to data integrity. It wi
Let me expand on Russell's expletives:
On Friday 06 June 2014 09:42:15 Thomas Güttler wrote:
>
> I guess a lot of developers don't want to hear the next lines:
>
> I think it is a "not invented here" syndrome: Ruby on Rails did it before.
> That's a reason to do it different.
>
This does deser
er methods to add the
>> select_related calls and "interpret" the type field properly; so I don't
>> see an
>> immediate need for inclusion in core.
>>
>> Well, you don't need select_related calls at all, if you're actually
>> storing thin
immediate need for inclusion in core.
Well, you don't need select_related calls at all, if you're actually storing things
in one table like "single-table
inheritance" implies.
I too was surprised to find Django doesn't do this, and was unable to find a
good third-pa
ll, you don't need select_related calls at all, if you're actually
storing things in one table like "single-table inheritance" implies.
I too was surprised to find Django doesn't do this, and was unable to find
a good third-party app that does it.
So I wrote my own: htt
On 05/22/2014 11:13 AM, Shai Berger wrote:
Any thoughts on this idea?
Instinctively -- isn't it possible to achieve the same things today by
overriding __new__ ?
My understanding is that achieving all the same things isn't possible.
The problem is that inside __new__ it is impossible to know i
On Thursday 22 May 2014 11:05:24 Anssi Kääriäinen wrote:
> I think it is time to add a new model classmethod from_db() to Django.
>
> The idea is to allow customization of object initialization when loading
> from database. Instead of calling directly model.__init__ from the queryset
> iterators,
On Monday 12 May 2014 12:27:01 Thomas Güttler wrote:
> >> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
> >>
> >> Are there reasons why it is used in django?
> >>
> >
> > Essentially, STI is a form of database denormalization.
On 05/16/2014 04:46 AM, Shai Berger wrote:
> On Monday 12 May 2014 12:27:01 Thomas Güttler wrote:
>> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
>>
>> Are there reasons why it is used in django?
>>
>
> Essentially, STI is a form of databas
On Monday 12 May 2014 12:27:01 Thomas Güttler wrote:
> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
>
> Are there reasons why it is used in django?
>
Essentially, STI is a form of database denormalization. I think Django should
not encourage this.
> I woul
This is already merged.
https://docs.djangoproject.com/en/1.6/topics/db/models/#multi-table-inheritance
Am Montag, 12. Mai 2014 11:27:01 UTC+2 schrieb guettli:
>
> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
>
> Are there reasons why it is used in django?
On Thu, May 15, 2014 at 4:11 PM, Christian Schmitt
wrote:
> This is already merged.
>
> https://docs.djangoproject.com/en/1.6/topics/db/models/#multi-table-inheritance
>
MTI is not STI, nor is it polymorphic.
Cheers
Tom
--
You received this message because you are subscribed to the Google Gro
Single Table Inheritance is used by ruby-on-rails and SQLAlchemy.
Are there reasons why it is used in django?
I would love to see a polymorphic inheritance solution in django.
I know that there are third party apps which provide this, but
something like this should be in the core.
There was
Dnia 2012-12-21, pią o godzinie 11:05 -0800, Anssi Kääriäinen pisze:
> I went with a different approach than the patch for 1.5. At this stage
> as minimal as possible change to get_default_columns() seemed like a
> good idea. See commit a0155f35343afbfd9e98ab9aa4615f06780f697e in
> stable/1.5.x.
>
On 21 joulu, 16:39, Krzysztof Jurewicz
wrote:
> On 13.12.2012 15:54, Anssi K ri inen wrote:
>
> > Second, I have created a patch which should allow your work to
> > continue working in master. See
> >https://github.com/akaariai/django/commit/94c417d2a29a0f72b26019fc38e...
> > - the idea is to chan
On 13.12.2012 15:54, Anssi Kääriäinen wrote:
Second, I have created a patch which should allow your work to
continue working in master. See
https://github.com/akaariai/django/commit/94c417d2a29a0f72b26019fc38ef400420097aa4
- the idea is to change get_fields_with_model() so that it doesn't
return
Third, I think it is a good idea to add more abstraction between the
ORM and the Model/Fields layer. So, in this way I do support the idea
of using proxy models for single table inheritance. On the other hand
it should not be surprising if in the future "different fields than
parents"
nheritance hierarchy for Proxy models with
> > automatic type recasting. I've written a fork of it with additional
> > possibility of adding fields to subclasses, therefore achieving a single
> > table inheritance implementation similar to Ruby on Rails' STI.
>
> Refr
n a fork of it with additional
possibility of adding fields to subclasses, therefore achieving a single
table inheritance implementation similar to Ruby on Rails' STI.
Refreshing this thread because it looks like my fork stopped working
properly with recent Django master. I suspect that commi
ecasting. I've written a fork of it with additional
> possibility of adding fields to subclasses, therefore achieving a single
> table inheritance implementation similar to Ruby on Rails' STI. This is
> possible mostly thanks to metaclass magic and monkey patching.
>
> The for
sibility of adding fields to subclasses, therefore achieving a single
table inheritance implementation similar to Ruby on Rails' STI. This is
possible mostly thanks to metaclass magic and monkey patching.
The fork's homepage is at https://github.com/KrzysiekJ/django-typed-models.
N
If you need to be able to filter and search across models, you could
try haystack.
http://docs.haystacksearch.org/dev/searchqueryset_api.html#filter
I've setup a site with a real base class, done queries on that and
then returned the child classes. It worked, but it felt pretty hacky
all the way
e to write
> Document.objects.all(). I'd then like to be able to iterate over this
> enumerable and have each object cast to its proper class.
>
> This is something accomplished with single table inheritance in Rails;
> why don't we have the equivalent in Django?
>
> I kno
Am 29.03.2011 um 20:46 schrieb Shawn Milochik:
> They can create a custom manager on the abstract class that would
> return an iterable, perhaps using itertools.chain() of the querysets.
>
> It depends on what they expect to do with the output of this custom
> manager, and they'd obviously lose
On 03/29/2011 02:46 PM, Shawn Milochik wrote:
> I'm not proposing a change to Django itself or suggesting that this
> should be a standard practice. I do think that this is a fairly clean
> solution for an individual to use to solve this problem if they have
> it.
>
> They can create a custom ma
On Tue, Mar 29, 2011 at 2:21 PM, Carl Meyer wrote:
> Hi Shawn,
>
> What you've outlined here is certainly possible (and yes, you'd need to
> subclass the ModelBase metaclass). I haven't looked at the abstract
> inheritance stuff recently, but I think there would be some alternative
> ways for the
Hi Shawn,
On 03/29/2011 01:28 PM, Shawn Milochik wrote:
> Hopefully someone on the core dev team can let me know if this is
> possible in Django. If so, it will solve this problem.
> I am not familiar with custom metaclass stuff done within models.Model.
>
> 1. Create a custom metaclass as descri
On Tue, Mar 29, 2011 at 11:40 AM, Carl Meyer wrote:
> On 03/29/2011 12:40 PM, Jeremy Dunck wrote:
>> What about keeping abstract inheritance in this case, but allowing
>> Document.objects.* to work by returning instances of the subclasses.
>> Filtering, etc. would only work based on the Document b
Hopefully someone on the core dev team can let me know if this is
possible in Django. If so, it will solve this problem.
I am not familiar with custom metaclass stuff done within models.Model.
1. Create a custom metaclass as described in "Pro Python," page 124.
2. Add this metaclass to the abstra
Cool.
Well, maybe I can look into how abstract base classes are currently
implemented and see if there's a way to generate query sets for all
derived classes from the parent.
Thanks for the insight!
On Mar 29, 12:40 pm, Carl Meyer wrote:
> On 03/29/2011 12:40 PM, Jeremy Dunck wrote:
>
> > What
On 03/29/2011 12:40 PM, Jeremy Dunck wrote:
> What about keeping abstract inheritance in this case, but allowing
> Document.objects.* to work by returning instances of the subclasses.
> Filtering, etc. would only work based on the Document base class.
>
> It would mean doing some unions, but would
On Tue, Mar 29, 2011 at 11:11 AM, Carl Meyer wrote:
> Hi Jordan,
>
> On 03/29/2011 11:40 AM, Jordan MacDonald wrote:
>> I have three models, structured like so:
>>
>> Document
>> -Presentation
>> -Spreadsheet
...
>> I'd like to be able to write
>> Document.objects.all(). I'd then like to be able
mes where I want to list/
> search across all documents, and I'd like to be able to write
> Document.objects.all(). I'd then like to be able to iterate over this
> enumerable and have each object cast to its proper class.
>
> This is something accomplished with single table inherit
is something accomplished with single table inheritance in Rails;
why don't we have the equivalent in Django?
I know I could just use the Document class and have a type field, but
then I have to do all of the type checking legwork manually. I was
hoping Django would handle normalizing/d
36 matches
Mail list logo
