On 1/15/08, Tobias Schlitt <[EMAIL PROTECTED]> wrote: > Design > ------ > > The proposed solution is to add a columnType property for all > definitions where a column is defined. The columnType can be one of the > PDO PARAM_ type parameters and directly defines the parameter type > provided to PDO when building the queries. > > This currently affects: > - ezcPersistentObjectIdProperty (definition) > - ezcPersistentObjectProperty (definition) > - ezcPersistentSession (usage) > > Open questions > -------------- > > > It would be nice to make large binary data available as a resource > > both for > writing and reading. PDO::PARAM_LOB can handle this if > > used together > > with PDO::FETCH_BOUND. Should we, and how do we make this available > > to the user? Write support will most probably work out of the box. If > > the value is a resource the whole file will be read automatically by > > PDO as long as PARAM_LOB is used. > > > This is not possible with the current design for PersistentObject, since > we only bind values and not parameters. We could only support this in > the load() method, where the SELECT query is build completly internally > and cannot be modified by the user. Everywhere else we would need to > keep track of the bound variables and can not rely on correctly bound > parameters when using find(). In addition, this functionality seems to > be broken in MySQL and SQLite (see: http://bugs.php.net/bug.php?id=40913). Alright, we should take a look at that for any later version of PO then.
> > > Should we use the PDO::PARAM_BOOL/INT by default? That is do we > > actually want to require to use this for anything else than PARAM_LOB > > since ints/bools etc. actually work fine already. What does using > > these parameters gain us. > > It does not work for those parameter types in all cases (referring to > DR) so we should support all of them. Since ezcDbQuery::bindValue() uses > PDO::PARAM_STRING as default, we can silently rely on this as the > default for PersistentObject definitions, too. Hmm, I remember when testing this (long time ago) that there were abnormalities. Did you test what actually works and what doesnt in the various databases. Or let me put it another way: what is actually supposed to work and what is not (derick?)?. Hard to choose what is right if we don't know what we're working with :) Cheers, Frederik -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
