[Dbix-class] Re: InflateColumn impact on ResultSet searches

[Eric Waters]

So, <mst> says this needs to be in SQL::Abstract, and that seems like a great idea.

Is there anyone out there working on SQL::Abstract to provide a callback API so DBIx::Class can filter things like DT objects but within the scope of the SQL::Abstract parser?  If not, I may be able to spend some time towards this goal.

Our conversation in #dbix-class:

[17:45:55] <mst> basically, SQLA can't do it itslef
[17:46:02] <mst> first step is to figure out a callback API
[17:46:07] <mst> and RFC that out to the DBIC list
[17:46:16] <mst> ideally, SQLA needs to become two layers
[17:46:24] <mst> a DWIM -> explicit query parser
[17:46:31] <mst> and an explicit query -> SQL generator
[17:46:41] <mst> then the first layer can be used in resultset
[17:46:54] <mst> with callbacks to filter things like DT objects
[17:46:58] <mst> and the second lives in storage
[17:47:06] <mst> with a callback to unroll a $rs into a subsel etc.

Eric

On Fri, May 25, 2007 at 05:22:06PM -0600, Eric Waters wrote:
> InflateColumn::DateTime overloads inflate/deflate, but doesn't affect search conditions.
> 
> So, while ref($row->dte) == 'DateTime', if you were to do a search for a particular value of dte:
> 
>   $rs->search({ dte => DateTime->now() })
> 
> ... the DateTime object would be passed to SQL::Abstract where it would be stringified.  This is not intuitive.
> 
> While I'm told by <ilmari> that this is being worked on in a SQL::Abstract refactoring, I didn't want to wait.  Below is a patch on DBIx::Class::ResultSet that will deflate any references found in the WHERE args before submitting to the driver.  I've put this here rather than at the Storage level because it seems that the result_source data (which seems to contain the column_info data that InflateColumn modifies) is not available further down the chain.  While it'd be nice to include this in DBIx::Class::InflateColumn, I don't see a way to do that.  Please let me know if I'm off base here.
> 
> With the attached code, one would be able to do a search using a ref and have it behave the same as getting/setting the value on a row.  This end behavior is more intuitive.  This is not throughly tested.
> 
> Eric Waters