Hi all! In trunk/PersistentObject/design/design-1.4.txt there were some open questions regarding improved datatype support in respect to binary data (issue #10151). I commented these questions and would like to receive feedback from you, before I start implementing it. Find the affected main section pasted below. For the questions/answers see the sub-section "Open questions".
Improved datatype support (especially binary data) [#10151] =========================================================== Background ---------- PDO uses several different ways of binding parameters to queries. Currently these are: - PDO::PARAM_BOOL - PDO::PARAM_NULL - PDO::PARAM_INT - PDO::PARAM_LOB - PDO::PARAM_STR (default) - PDO::PARAM_INPUT_OUTPUT Currently unsported by PDO. Used for in/out parameters of a stored procedure. Currently only the default paramter PARAM_STR is supported by persistent object. This does not mean that you can not store integers and booleans as the database drivers will figure this out themselves. However, for some field types especially you are required to use parameters. An example of this is binary data which can contain '\0'. If you use the default parameter PDO::PARAM_STR the remaining data will simply be ignored since the end of the string has already been encountered. The support for PDO PARAM_ types was recently added to the Database component as a fix for issue `#010943`_. .. _`#010943`: http://issues.ez.no/IssueView.php?Id=10943 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). > 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. Thanks for any comment. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
