with the db-mapping?
I'm finding it extremely useful to map my tables to custom
Zend_Db_Table subclasses,
and set them up to return objects of custom of Zend_Db_Table_Row subclasses .
I extend the row class with custom methods for inspecting and manipulatiing
them in no-trivial ways, and can still just save them afterwards. So
far so good.
The problem arises when want to extend the class not just with methods
but also with variables. Variables that do not match any db column. This is
useful for caching the results of expensive operations, and to be able to use
the same instance as return value for several calls). If I simply add a custom
variable, save will not work, no matter what access policy I put on on it.
Is there any way to exempt variables from the automatic db-mapping without
going deep behind the curtain?
Are there any builtin variables that could be used to 'hang' my custom data
under without disturbing how the rest works?
If not, consider this a feature request.
Some possible designs, in my order of preference:
1) A flag that exempts all 'private' and 'protected' fields from mapping,
not just the builtin ones.
2) A prefix that will exempt any variable names starting with it
3) An overridable method that clears an attribute name for db-mapping
(this should probabaly be the underlying mechanism anyway, the default
implementation perhaps being one of the above)
4) A builtin "extra" protected field that is never included, just like the
other builtins, dedicated to user data.
没有评论:
发表评论