Hi! On 02/17/2009 02:19 PM Gaetano Giunta wrote: > - looking at the issue #012470, I found out that current ezpo code casts > object properties to the declared php type before serializing them into > the db, instead of doing that when extracting them out of the db. Am I > the only one thinking this is done backwards? After all they will be > cast anyway by the bind done in PDO a few lines of code later... Otoh it > would be nice to have the fetched data cast to say, php bool, even if > the underlying db does not support it natively
Some PDO drivers have issues, if they do not receive the correct PHP values corresponding to the database type. I agree with you, that we should also have the casting when loading data from the DB to ensure proper PHP types. However, this is a feature request and needs to be made configurable to maintain BC. I don't think this will make it into the next release, since we are all quite busy. > - reading the online tutorial, I find this code a bit clumsy: > > $def->properties['name'] = new ezcPersistentObjectProperty > > <http://ezcomponents.org/docs/api/trunk/PersistentObject/ezcPersistentObjectProperty.html>; > > $def->properties['name']->columnName = 'full_name'; > $def->properties['name']->propertyName = 'name'; > $def->properties['name']->propertyType = > ezcPersistentObjectProperty::PHP_TYPE_STRING > > <http://ezcomponents.org/docs/api/trunk/PersistentObject/ezcPersistentObjectProperty.html#PHP_TYPE_STRING>; > > why is it needed to use 'name' both as key of the properties array of > the definition object and at the same time specify it in the property > itself? This is necessary to ensure proper reverse lookup while loading objects from the DB. We setup a reverse lookup table (column name -> property name) to achieve this. Here the property name is no more available as the key and we need the propertyName field to determine it. If we remove the constraint to have the property name as the key in the initial definition, we need to setup both lookup tables on fetching the definition, which would mean more overhead here. I don't see a real problem here. It might not be the most convenient way of configuration, but it still works very fine. > // here: check if $offset corresponds to $value->propertyName > // if $value->propertyName === '', set it to $offset > // else if $value->propertyName !== $offset, raise an exception > parent::offsetSet( $offset, $value ); We could properly do that. But it will add magic where no magic is required, which makes things more obscure for users. Therefore I dislike this addition. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer t...@ez.no | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
