I have been tinkering around with php peanuts and am very pleased with its flexibility. Yet, I have encountered something that could probably be improved.
Currently, phpPeanuts gives every PntDbObject an id, used to identify the object in the database. This means that every database table needs an "id" field.
Yet, sometimes this is not what you want. For example, I have a table with objects and a table with properties. This means I can associate arbitrary properties with objects, without modifying the database layout.
I also have a table containing property values. This table has three fields, objectId, propertyId and value. This table associates every object/property combination with a value. Every row in this table is identified by the combination of objectId and propertyId. Yet, to model these property value objects in Peanuts, I have to add a fourth field "id", to also identify the property value.
I think it should be possible for a PntDbObject to have an arbitrary number of fields in the identifier. By default this would just be 1 field, called "id". Through a function such as "PntDbObject::setIdentifier($array_of_field_names)" one could set the identifier (or perhaps use "PntDbObject::getIdentifier()", which could be overriden in subclasses?)
As far as I can see, this could be implemented without to much hassle, but my view of the peanuts codebase is still far from complete. Any thoughts?
henk
2006-06-07 17:53:31
Hi Matthijs,
thanks. Of course this has been a design issue. I know the relational model allows composite (foreign) keys, and at school i was told to use the combination of columns as key that would identify each record uniquely. They gave examples with columns that where holding values that are visible to the end user. They never told me what mess i would be in when an end user decides to change one of these values but not wants to create a new record. My conclusion: don't show keys and foreign keys to end users, and certainly don't suggest that there is any other meaning to them then an internal identifier.
From this point of view the invisible keys will have to be generated by the software. They may be composite, but there is no advantage in that, it only makes things more complicated. As phpPeanuts is meant to be the simpelest thing that could possibly work (for MDD) it does not support composite keys. To make thinks even simpeler, phpPeanuts assumes this single key column is mapped to a property called 'id' and foreign key columns are mapped to a property named '<navigationalPropertyName>Id'. It should be possible that you choose your own mapping (set the colunmName of the property you want a non-default mapping for), but it is a 1 to 1 mapping.
I realize that this limits phpPeanuts' usability for working with existing databases. Probably the simpelest solution is creating views in your database and have phpPeanuts work against those views. But i am not sure that this will really solve the problem, i am not familiar with database views.
Of course you could try to specialize, of even modify the framework to support compostie keys, but you will find it does not end with PntDbObject. Several page classes use the id property to identify the object they work on. Derived properties (including multi value properties) use it (and its foreign id counterpart) to implement navigation. PntDbClassDescriptor uses it as a key to cache obects in an associative array. List- and dialogwidgts use them to identify the selection, and PntSqlJoinFilter uses them for navigational queries. And then there is this ugly code below EditDetailsPage and SaveAction, in and around pnt/web/dom that was never really finished... I would not recommend this.
Greetings,
Henk Verhoeven.
Post Edited (06-08-06 10:26)
Add a Reply
Loading form, please wait
The website will not send you an e-mail when a reply is added to this topic
I have been tinkering around with php peanuts and am very pleased with its flexibility. Yet, I have encountered something that could probably be improved.
Currently, phpPeanuts gives every PntDbObject an id, used to identify the object in the database. This means that every database table needs an "id" field.
Yet, sometimes this is not what you want. For example, I have a table with objects and a table with properties. This means I can associate arbitrary properties with objects, without modifying the database layout.
I also have a table containing property values. This table has three fields, objectId, propertyId and value. This table associates every object/property combination with a value. Every row in this table is identified by the combination of objectId and propertyId. Yet, to model these property value objects in Peanuts, I have to add a fourth field "id", to also identify the property value.
I think it should be possible for a PntDbObject to have an arbitrary number of fields in the identifier. By default this would just be 1 field, called "id". Through a function such as "PntDbObject::setIdentifier($array_of_field_names)" one could set the identifier (or perhaps use "PntDbObject::getIdentifier()", which could be overriden in subclasses?)
As far as I can see, this could be implemented without to much hassle, but my view of the peanuts codebase is still far from complete. Any thoughts?
thanks. Of course this has been a design issue. I know the relational model allows composite (foreign) keys, and at school i was told to use the combination of columns as key that would identify each record uniquely. They gave examples with columns that where holding values that are visible to the end user. They never told me what mess i would be in when an end user decides to change one of these values but not wants to create a new record. My conclusion: don't show keys and foreign keys to end users, and certainly don't suggest that there is any other meaning to them then an internal identifier.
From this point of view the invisible keys will have to be generated by the software. They may be composite, but there is no advantage in that, it only makes things more complicated. As phpPeanuts is meant to be the simpelest thing that could possibly work (for MDD) it does not support composite keys. To make thinks even simpeler, phpPeanuts assumes this single key column is mapped to a property called 'id' and foreign key columns are mapped to a property named '<navigationalPropertyName>Id'. It should be possible that you choose your own mapping (set the colunmName of the property you want a non-default mapping for), but it is a 1 to 1 mapping.
I realize that this limits phpPeanuts' usability for working with existing databases. Probably the simpelest solution is creating views in your database and have phpPeanuts work against those views. But i am not sure that this will really solve the problem, i am not familiar with database views.
Of course you could try to specialize, of even modify the framework to support compostie keys, but you will find it does not end with PntDbObject. Several page classes use the id property to identify the object they work on. Derived properties (including multi value properties) use it (and its foreign id counterpart) to implement navigation. PntDbClassDescriptor uses it as a key to cache obects in an associative array. List- and dialogwidgts use them to identify the selection, and PntSqlJoinFilter uses them for navigational queries. And then there is this ugly code below EditDetailsPage and SaveAction, in and around pnt/web/dom that was never really finished... I would not recommend this.
Greetings,
Henk Verhoeven.
Post Edited (06-08-06 10:26)