Matt S Trout
dbix-class at trout.me.uk
Tue Aug 2 10:51:40 CEST 2005
On Tue, Aug 02, 2005 at 10:25:10AM +0200, Emanuele Zeppieri wrote:
> > [...]
> > Maybe you could provide some use cases for joins for me to incorporate
> > into my planning rather than just telling me a module we aren't using
> > doesn't support them? :)
> Ouch! I really didn't mean to be provocative ;-)
And I didn't mean to be quite that sarcastic in my reply :)
But seriously, lob some joins at me. I'm collecting them for when I
implement. Weird ones that span multiple tables and multiple join types
with multiple conditions on each join are good.
> I could further speculate that, in general, raw SQL plus some user
> provided metadata is an easier route (both for you and the users of
> your module) than the burdensome task of replicating every SQL construct
> (consider also the proprietary extensions) in a new abstract-like
An example: join conditions in Relationship.pm are expressed in abstract
syntax and can be resolved to *either* the appropriate stuff for whatever
JOIN foo ON clause you're assembling *or* a WHERE clause based on being
handed an object for one side of the relationship. If I didn't use abstract
syntax for that I'd have to either de-parse the SQL into some abstract syntax
(ta-dah) or regex the thing (far too fragile).
And if we're going to need abstract syntax for some of our SQL, I'd much
rather use it for everything - if we can't be legible, at least we can be
consistently illegible :)
> I want also to stress that I'm very grateful to you for you great work,
> and my criticism is intended *only* to try to contribute to your work.
Ok. Let's get this out of the way now. I'm a sarcastic bastard. I tend to
debate hard. I don't take the internet personally, and I'd prefer it if
nobody on the internet took *me* personally either.
Anybody who feels I'm sounding unduly aggressive at any point should please
speak up - I have no wish to upset people but I'm very hard to upset myself
so I have a tendency to mis-judge :)
> > I'm a great believer in "let the user get at the
> > raw stuff if they want" but also in "but make sure they know
> > that's what they're doing and the downsides are their problem"
> > - hence wanting to mark it non-core at some stage.
> Great. That was exactly what I was hoping for.
And anyway, retrieve_from_sql is *still* going to stay in the core for
a while; I just wanted to make sure there weren't any showstopping reasons
for it not being the One True Way To Do Things later, because I suspect that's
going to have to be the case.
Matt S Trout Website: http://www.shadowcatsystems.co.uk
Technical Director E-mail: mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.
More information about the Dbix-class