[Dbix-class] Twiddling SELECT lists and WHERE clauses

Peter Rabbitson rabbit+dbic at rabbit.us
Sat Sep 10 15:13:09 GMT 2011


BOn Fri, Sep 09, 2011 at 01:33:44PM -0700, dorian taylor wrote:
> Hey guys,
> 
> I have a set of queries that do virtually the same thing over three
> different initial result sources. Elements of the WHERE clause are
> present in each of them, but sometimes I need to refer to me.colname,
> sometimes relname.colname. The same goes for the SELECT list.

Show your actual use case, as the answer will differ depending on which
part exactly you want to streamline/abstract away.

> My instinct is to do some sort of thing which reads the join structure
> and figures out from the point of view of the initial position which
> columns to rename 'me.' and which to rename 'relname.'.

Don't do that, it is much much much harder than you can possibly imagine.
A naive implementation will appear to work until it stops doing so.

> I figure
> though that there must be some existing facility for at least part of
> this.

There is an internal facility to manage the from spec, however it is
still under very heavy development, thus not suitable for general API
consumption.

> I see for example that there are +select and +as operators, as
> well as the merging of WHERE clauses when searches on result sets are
> called in succession.

The where condition merging is stateless, and so is the select spec
(the +as operator does not influence the SQL generation, it is there to
deal with parsing the returned result).

> I suppose I could just fully qualify the
> underlying table names rather than use the generated aliases, but I'm
> concerned about side effects.

You can not do this, as most engines do not allow you to refer to the
original table name once you aliased it to something else.

Bottom line - show us what you want to do so that a correct answer can
be delivered :)

Cheers!



More information about the DBIx-Class mailing list