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
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
