to_DB handler in WHERE

[Sergiy Zuban]

Hi Laurent,

Idea of to_DB/from_DB handlers is awesome, but it lacks support for WHERE clause to make everything transparent.

I've been trying to automate this using dirty hack (using custom Statement class with overridden select method) like this:

        bless $where, $schema->table('Foo')->metadm->class;

        $where->apply_column_handler('to_DB');

        unbless $where;

but it works only for scalar values. Since WHERE conditions are actually handled via SQL::Abstract values can be more complex, so I think much better way to

implement that is to call to_DB handler internally (after SQLA) right before binding a value.

As another benefit with this approach there will be no need to explicitly specify DBMS-specific types (recently implemented feature) with each call in WHERE clause.

Do you think it's technically possible to improve this in further versions or there were some reasons to don't call handlers for values in WHERE?

--

Sergiy Zuban

[laurent dami]

--
 
---
You received this message because you are subscribed to the Google Groups "dbix-datamodel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbix-datamode...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Hi Sergiy,

Of course it would be ideal to automatically apply "to_DB handlers" (a.k.a. deflators) within WHERE clauses; but unfortunately the way these clauses are expressed within SQLA doesn't give us enough information to automatically decide which handler goes where : there could be many problems with literal SQL chunks, SQL functions applied to columns, column comparisons ( -where {foo => {-ident => 'bar'} ), column or table aliasing, column homonymy, etc.

If I remember well, DBIx::Class has the same problem (that's why I put Ribasushi in copy of this message).There is a grand project by Matt Trout of rewriting SQL::Abstract on top of an abstract syntax tree (see https://metacpan.org/module/Data::Query ); and Matt tries hard to keept it compatible with existing stuff; however this is very ambitious, so I don't know when it will be ready, nor if it will still work with DBIx::DataModel.

If that project succeeds, it will probably provide a sane foundation for walking through the abstract tree and applying handlers to values;  however quite a lot of integration work will still be needed to make the whole thing work in DBIDM through all architectural levels.

In short, there is unfortunately very little hope of improving on this in the near future.

Cheers, Laurent D.