Hello, Lee, 2007/4/13, Lee Standen <[EMAIL PROTECTED]>:
Or, you could take the other tact, and argue that it should be something which is handled on the Perl side...my $rs = $schema->resultset('Patient')->search({ -and => [ first_name => { like => 'J%' }, birth_date => { '>' => time - 20 * SECONDS_IN_YEAR } ] }); Yes, while it's POSSIBLE to do that in an SQL statement, I prefer to think as DBIx::Class not as an SQL abstractor, but as a data object extractor, which means anything that requires me to use SQL specific commands is bad :) I would ideally like to see DBIx::Class eventually have backend modules for things like LDAP, CSV and other non-SQL storage types :)
I see what you mean. But it is just a workaround for this particular example. And not quite precise, by the way. DB server and an application may reside in different time zones. On the other hand, you are right, that one should think about DBIC as a serialization class. But since we have a possibility to search through objects, and moreover this search is based on columns in the database, not on object's properties (this is another great defect in DBIx::Class - IMHO), we cannot regard DBIx::Class as a pure abstraction. Regards, Ivan _______________________________________________ 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]/
