[Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241

[Peter Rabbitson]

On Fri, Feb 22, 2013 at 11:45:54AM +0000, Will Crawford wrote:
> On 22 February 2013 11:36, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> 
> 
> > At first glance yes. The problem here is that you are incorrectly
> > assuming that given 'concept.concept_id' one can simply infer we are
> > talking about the 'concept' from join => { element => 'concept' }.
> >
> > However the moment *another* 'concept' appears, possibly due to chaining
> > somewhere deep in your app - what do you do? Here is a real test case: [1]
> 
> 
> That problem already exists when referring to the alias of a
> joined/prefetched table in the 'select' list or search specification,
> though - this wouldn't introduce any *new* ambiguity at all, surely?

Incorrect - the 'select' argument takes proper storage-side aliases to 
pass to the SQL generator (currently SQL::Abstract). So in the example 
case you can specify artist.foo or artist_2.foo and everything will 
remain correct. Furthermore frew is working on functionality to allow 
specification of custom alias-names for each node in a thejoin/prefetch 
structure. So that is currently unambiguous but obtuse, and in the 
future will just get easier.

The 'as' specification however is in essence an "inflation_map" (we may 
end up renaming this attribute - it is too confusing as it stands (while 
maintaining backcompat obviously)). In the inflation map there is no 
place for alias interpretation - the map is strictly mirroring the 
current relationship graph of your schema. So again - heuristics on the 
contents of inlation_map/as is *not* something that the core of DBIC can 
provide as it falls squarely in the 80/20 good-enough realm.

And to reiterate - a ResultSet role/component implementing such 
"guessing" is very easy to write and CPANize.