ORM join failures (again)

40 views
Skip to first unread message

Fred Condo

unread,
Feb 13, 2014, 3:08:18 PM2/13/14
to silverst...@googlegroups.com
I would like to raise awareness of a class of flaws in the ORM where it fails to join the tables of subclasses in rather trivial use cases. There doesn’t seem, in my opinion, to be enough urgency surrounding such fundamental regressions (such use cases worked in 2.4).

https://github.com/silverstripe/silverstripe-framework/issues/2846
https://github.com/silverstripe/silverstripe-framework/issues/1682
https://github.com/silverstripe/silverstripe-framework/issues/1683


Mark Guinn

unread,
Feb 13, 2014, 3:33:28 PM2/13/14
to Fred Condo, silverst...@googlegroups.com
+1 for that. I’ve hit that bug 2 or 3 different times on my last project.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/groups/opt_out.

Michael van Schaik

unread,
Feb 13, 2014, 3:50:16 PM2/13/14
to silverst...@googlegroups.com

+1 here as well

Op 13 feb. 2014 21:08 schreef "Fred Condo" <fco...@quinn.com>:

Daniel Hensby

unread,
Feb 13, 2014, 6:07:58 PM2/13/14
to silverst...@googlegroups.com
I think all these problems are from the lazy loading implementation. Has there been any objective measurement on what kind of performance impact the lazy loading of objects actually has?

I'm not talking about DataLists and the ongoing building of queries, I mean not getting data and populating objects until requesting them specifically?

Really, DBs are a bottlekneck, not storing or parsing the results into objects (though that has overhead of course). In Laravel I like how one can request an object PLUS some of its relations in one go to save a DB call. It seems SS is about making more calls with the aim of reducing data transfer, rather than less calls with the aim of reducing DB workload.

Anyway, someone with an intricate knowledge of the lazyloading, DB manipulation / query building and versioned needs to address this joining/sorting bug (and others) which in theory is simple to solve except for when the versioned decorator comes in to play.

Mark Guinn

unread,
Feb 13, 2014, 6:21:15 PM2/13/14
to silverst...@googlegroups.com
Good point about being able to ask for deeper levels of joins in one query. If you're displaying a grid of products (not an uncommon task) it's easy to hit 300-400 queries on a single page with things like looking up parent records for Link() and images.

Daniel Hensby

unread,
Feb 13, 2014, 6:26:05 PM2/13/14
to silverst...@googlegroups.com
Yes. Though I thought those parent calls were cached! It'd be nice to have those extra joins on by default "grab Page with Parent" type of thing. That should probably be on by default for all pages!

Fred Condo

unread,
Feb 24, 2014, 2:50:33 PM2/24/14
to silverst...@googlegroups.com
Damian Mooyman has given some attention to #2846 (thanks!). I hope other core devs will also have a look.
--
Fred Condo, Ph.D. <fco...@quinn.com> +1(415)349-5579 Skype:fredcondo
Chief Engineer, Quinn Interactive, Inc. http://quinn.com
Web design and development since 1994.
Reply all
Reply to author
Forward
0 new messages