On returning appropriate subclass instances when querying a model with subclasses

[Andrea Zilio]

Hi all,

Here's what I'm talking about:
You have 3 models: Place, Restaurant and Cinema where Restaurant and
Cinema both inherits from Place.
So in the database you have some simple places, some places which
really are Cinemas and some places which really are Restaurants.

Well, I think that this should be possible:
>>> Place.objects.all()
[, , , ]
(Current implementation only returns Places objects)

This seems to have been taken into account here:
http://code.djangoproject.com/wiki/ModelInheritance#a2.ModelingjoinsinSQL
In that wiki page it's said that this should be possible using LEFT
JOINS, but that this approach could drive to a lot of overhead as the
subclass count increase.

But... What about allowing this kind of query-including-subclasses by
requesting it in an explicit way?
Something like this?
>>> Place.objects.select_subclasses(Cinema,Restaurant).all()
[, , , ]
>>> Place.objects.select_subclasses(Cinema).all()   # Here we ask to join ONLY 
>>> with Cinema
[, , , ]

Maybe this has been previously discussed but I couldn't find any
ticket or any discussion about it.
So take this as a proposal if it wasn't already discussed or as a
request to have some info about the previous discussion.

Thanks in advance

P.S.
SqlObject seems to have implemented something like this
http://www.sqlobject.org/Inheritance.html

--~--~-~--~~~---~--~~
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: On returning appropriate subclass instances when querying a model with subclasses

[Andrea Zilio]

Thanks! I think I've found the discussion you're talking about:
http://groups.google.com/group/django-developers/browse_thread/thread/7d40ad373ebfa912/a20fabc661b7035d

So seems that this idea was in fact rejected because of the O(# of
nodes in the inheritance tree) joins
needed to get all the fields from subclass tables.

But the idea of letting this as an optional way to retrieve data (so
not the default way, but by using something like
QuerySet.select_subclasses() as suggested on my previous email) could
be a solution to this problem or not?

Moreover I've dug a bit on how Hibernate handles inheritance and
indeed it always make outer joins to subclasses (it has to since it
doesn't use a discriminator column and returns, by default, instances
of subclasses when querying for a base class).

Anyway, what do you mean by "end-user add-on to models"?
Where can I find info to make such an add-on? Or are you just talking
about editing the django source code on my installation?

Thanks again ;)
Andrea

On Aug 23, 10:25 am, Russell Keith-Magee 
wrote:
> On Sun, Aug 23, 2009 at 9:18 AM, Andrea Zilio wrote:
>
> > Hi all,
>
> > Here's what I'm talking about:
> > You have 3 models: Place, Restaurant and Cinema where Restaurant and
> > Cinema both inherits from Place.
> > So in the database you have some simple places, some places which
> > really are Cinemas and some places which really are Restaurants.
>
> > Well, I think that this should be possible:
> >>>> Place.objects.all()
> > [, , , ]
> > (Current implementation only returns Places objects)
> ...
> > Maybe this has been previously discussed but I couldn't find any
> > ticket or any discussion about it.
> > So take this as a proposal if it wasn't already discussed or as a
> > request to have some info about the previous discussion.
>
> This has been discussed, at length, and rejected. If you search the
> django-dev archives, the discussion happened around the time that
> model inheritance was being added to the ORM. For the most part,
> you're looking for a series of discussions between myself and Malcolm.
> Using "CORBA" as a keyword in your search will help (and if you know
> anything about CORBA, will also explain why the idea was ultimately
> rejected).
>
> The techniques to achieve this sort of thing are well known and well
> established, but they do come at a cost. We opted not to wear that
> cost by default in inherited models. If you want this capability, it
> (or something functionally equivalent) can be added as an end-user
> add-on to models.
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
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: On returning appropriate subclass instances when querying a model with subclasses

[Andrea Zilio]

Great, but that wasn't exactly what I was looking for.

What I need is a way to get the right instances from a *single* query.

This means that I should do LEFT JOINS on direct subclasses of the
base class.

What I need to know is if this is somehow possible without editing the
Django core, but using some signals ore something else.
Or if this is planned for some future release.

I need to do something like this:
http://groups.google.com/group/django-users/browse_thread/thread/2d1c286b37a153d3

Thanks in advance ;)
Andrea

On Aug 23, 3:06 pm, Marc Fargas  wrote:
> On Sun, Aug 23, 2009 at 1:54 PM, Andrea Zilio  wrote:
>
> > So seems that this idea was in fact rejected because of the O(# of
> > nodes in the inheritance tree) joins
> > needed to get all the fields from subclass tables.
>
> You may want to loook at Alex's post on the 
> subject:http://lazypython.blogspot.com/2009/02/second-look-at-inheritance-and...
> a solution to apply on your own projects.
>
> Note that his code was written before Malcolm wrote proxy classes, Alex's
> code could now be improved to not query the subclasses but return proxy
> classes to them effectively avoiding the O(#..) queries untill you try to
> access subclass data ;)
>
> Regards,
> Marc
--~--~-~--~~~---~--~~
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: On returning appropriate subclass instances when querying a model with subclasses

[Andrea Zilio]

So the answer to the question "Can I get the right instances with one
single and only DB query" seems to be:
"No, you cannot do so without touching the Django orm code".

Am I right?

On Aug 24, 1:52 am, Russell Keith-Magee 
wrote:
>
> > Or if this is planned for some future release.
>
> As I said previously, this isn't planned for a future release -  in
> fact, it's planned that we _wont_ do this.

I tried :)
--~--~-~--~~~---~--~~
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: Django Transaction Integrity

[Andrea Zilio]

Hi Piet,

I'm just a django user, but I like very much your clear explanation
about how django transactions works and what's wrong with them!

Great work!

Andrea

On 13 Mag, 17:01, Piet Delport  wrote:
> Hi,
>
> I'm working with a company that uses and maintains a commercial Django-based
> commercial system, which requires reliable transactional integrity across
> groups of database operations in a number of places (financial transfers,
> and so on).
>
> I've been investigating how Django's transaction management works, but found
> to my surprise that Django's transaction managed blocks do not actually
> ensure any transactional integrity, despite the documentation indicating
> otherwise. (For example, "Use the commit_on_success decorator to use a
> single transaction for all the work done in a function.")
>
> I wrote up the following document, which describes the problem in a fair
> amount of detail, as well as how Django's transaction management system may
> be fixed to avoid it:
>
>    - Django Transaction
> Integrity
>
> I'd like to use this as a starting point for discussion; specifically, i
> want to solicit feedback about the proposed solution approach (subsuming
> nested transaction blocks): Does it sound reasonable to change
> django.db.transaction's implementation to this?
>
> I know this is not a small change, but i think it should be worth it if
> transaction blocks are to be supported at all: there seems to be very little
> point in keeping the current implementation where declaring a transaction
> block doesn't actually make it transactional.
>
> (This probably affects a number of current Django tickets, including at
> least: #2227 ,
> #6669
> , #9964 )
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Analysis of Django Project

[Andrea Zilio]

Hello,

I'm a graduate Computer Science student and in my Open Source
Technologies class I've chosen Django as the project to write about in
my final exam paper.
So I'll write a short document (7-15 pages) about the vision, target,
innovative features, possible business models, development process and
community status of this project.

I'm not new to Django: I've already used it for more than a year in a
bunch of projects and I liked it (I came from PHP and used some PHP
frameworks in the past), so I already have some ideas about what to
write in this paper.

I'm writing here and opening this thread just because I would like to
know your opinions as django developers or contributors about some
ideas I have and that I'll cover in this document.
This explains why I've sent this message to django-developers and not
to django-users.

If this is not the appropriate place to write I'm sorry and in this
case I'll be glad to know if someone want to share his opinions
anyway, maybe contacting me directly via email.
Otherwise I'll soon post my first question for you in this thread (so
without creating separate discussions) waiting for your feedback.

Thanks in advance to everyone who will participate

P.S.
I'll probably write the document in english (I'm italian), so I'll be
happy to share it with you when finished if you want to. (eta: mid
july).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Analysis of Django Project

[Andrea Zilio]

So, Here I am.

The first thing I would like to talk about is what I think is the "big
idea" behind Django, related probelms and so to hear about your
opinion on this.

(If you're in hurry just skip to the conclusions reading the last
paragraph ;))

I think that the most important feature of Django framework is the
idea of creating websites aggregating multiple reusable applications.

The idea of reusing components is obviously one of the main principles
of software engineering and it is also widely used in many
environments, but before using Django I have never seen this simple
but brilliant idea in any other *web* framework.
Other frameworks may have plugins, helpers, and various libraries, but
no one shares the concept of build web sites building separate and
reusable applications.

In my opinion, there are two problems about this:
- this innovative difference and its consequences for the developers
are not well advertised. I mean that when someone comes to the Django
website to get an overview of the framework he usually don't get this
crucial idea.
- even when a django beginner user realizes that he could and should
develop different *reusable* applications in order to use them in the
current and future projects and so saving a lot of time, it is
difficult to understand how this can be achieved in practice.

So, the key benefit of using django is not well advertised in the web
site and, the worst, when someone discovers it, it is difficult to
find information about HOW to build reusable applications. I mean that
patterns such as how to organize configuration, how to organize
application files, how to allow easy subclassing of the application it
self, etc.. are not easy to be found and this maybe because there are
not yet standard and established ways to do so.

Instead a user is required to participate, search or listen to
technical Django talks to know about patterns on how to create
reusable applications, about how to organize files, about when to add
a feature to an existing app and when to avoid it, etc...

The result of this is that actually a lot (I think the great part) of
the contributed django applications available online on various web
sites (eg: github, googlecode, etc..) are in fact not easily
*reusable*, *configurable* or *extendable* and, if they were, the
advantage of using Django would also be more evident because building
websites with it would require more and easy integration of existing
applications then actual developing new apps.

Maybe advertising more about the benefits of django and, more
important, making available into the documentation it self patterns
about how to build reusable applications would reduce these problems.

I would like to highlight that I'm not criticizing anyone, I just have
this opinion and I think that it would be useful to share it with you
to improve the future versions of Django or maybe to realize that I'm
wrong.

So, I would like to know if you agree or disagree with me on the
points I've talked about, which are:
- the idea of reusable app is one of the biggest advantages of using
django
- no other famous and widely used *web* frameworks (es: cakephp, ror,
etc...) shares the same idea
- this idea is not well advertised (how many of us started developing
a website in a single and heavy application and only then realized the
"big idea" of reusable apps?)
- patterns to build actual reusable applications are not established
yet or they are not easily available to users to follow, resulting
(with some exceptions) in a lot of not reusable apps or apps
implementing their modularity in very different ways (not following a
patter or a standard method)

I'm really interested in your opinions :)
Andrea

On Jun 12, 12:56 pm, Russell Keith-Magee 
wrote:
> On Sat, Jun 12, 2010 at 6:10 PM, Andrea Zilio  wrote:
> > Hello,
>
> > I'm a graduate Computer Science student and in my Open Source
> > Technologies class I've chosen Django as the project to write about in
> > my final exam paper.
> > So I'll write a short document (7-15 pages) about the vision, target,
> > innovative features, possible business models, development process and
> > community status of this project.
>
> > I'm not new to Django: I've already used it for more than a year in a
> > bunch of projects and I liked it (I came from PHP and used some PHP
> > frameworks in the past), so I already have some ideas about what to
> > write in this paper.
>
> > I'm writing here and opening this thread just because I would like to
> > know your opinions as django developers or contributors about some
> > ideas I have and that I'll cover in this document.
> > This explains why I've sent this message to django-developers and not
> > to django-users.
>
> > If this is not the appropriate place to write I'm

Django Lines of Code

[Andrea Zilio]

Hi!

I was just wondering if anyone knows the total number of lines of code
of Django.

Andrea

-- 
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: Django Lines of Code

[Andrea Zilio]

Sorry for that, but thanks for the answer.

On Mar 28, 1:36 pm, Jacob Kaplan-Moss  wrote:
> On Mon, Mar 28, 2011 at 3:29 PM, Andrea Zilio  wrote:
> > I was just wondering if anyone knows the total number of lines of code
> > of Django.
>
> Hi Andrea --
>
> This question's off-topic for this list. Django-dev is for discussion
> development of Django itself, and the length isn't really relevant. In
> the future please help us try to keep the signal-to-noise ratio high
> around here, OK?
>
> Jacob
>
> PS: 66,045 lines of code plus 51,174 lines of tests.

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