Thanks again!
On 19 March 2013 13:09, Peter of the Norse <rahmc...@radio1190.org> wrote:
> [snip]
>
> We might put the onus on the client to call:
> qs = getTendersForContractor(contractor)
> for tender in list(qs.prefetch_related('project', 'project__contract',
> 'project__contract')):
> print tender, tender.getTotalCost()
>
>
> If this is really what you are doing, then I strongly recommend
> https://docs.djangoproject.com/en/dev/topics/db/aggregation/. This case
> is a single SQL statement.
>
> Not only is this complicated, but this requires the client know how the
> Tender is implemented (the prefetched would become uneccessary if we
> changed the implementation to store the total cost on the actual Tender
> itself at the cost of denormalised data). Note that you wouldn't have these
> problems if the data existed in memory.
>
> These points are making me rethink my data model and API design, and that
> the OO paradigm doesn't always fit well with web apps. In particular the
> slides at
> http://www.slideshare.net/OReillyOSCON/unbreaking-your-django-application:
>
> 23: "Django doesn’t have a good primitive for returning an object graph in
> one call. - multiple db trips required" Implies that object graphs like
> what I've designed is difficult to implement effeciently..?
>
> 24: "So, what do to? If you almost always return the parent along with
> the related object, consider object inheritance instead. That does do a
> nice join operation. Don’t create an insane class graph, though. If you
> frequently use the related object without reference to the parent object,
> use a foreign key." Not sure what 'object inheritance' is but might be
> useful, and concerned that I might be heading towards an 'insane class
> graph' (the real data model has 6 or 7 more related objects). Am I heading
> down the wrong path of embracing an OO style API and data model?
>
> I don’t know. But I think you have to acknowledge that there is such a
> thing as too OOP. I’m not sure that creating an API on top of Django is a
> good idea. Django is already super high level. I would have to ask myself
> how I expect my users to use what I give them. On some level, you’ll have
> to trust your user to ask for the data they need.
>
>
Getting the total cost isn't exactly what I was doing, I was trying to come
up with a simple example of a function on the class that can't
easily/cleanly be calculated by simply aggregating data from the related
objects. With this I think I've hit an impedance mismatch problem, from
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
"Unfortunately, fields within the object are only part of the problem--the
other problem we face is that objects are frequently associated with other
objects, in various cardinalities (one-to-one, one-to-many, many-to-one,
many-to-many), and an O/R mapping has to make some up-front decisions about
when to retrieve these associated objects"
Which is exactly the issue I'm having. As you've stated there isn't a
straight forward solution, and I'll have to consider tradeoffs in my design
decisions.
Taras
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
