Hello,<br><br>Has anyone implemented in Storm an useful approach to separating application logic from the __storm_table__ classes (which I usually call 'entity' classes)? For purposes of this discussion, I'll use the word 'model' to describe classes which contain the app logic but which operate on the entity classes.<br>
<br>After spending some time writing custom code to map entity attributes to our 'model' classes, we hit a brick wall trying to use store.find, which always returned an instance of the entity (the original __storm_table__ object) instead of the 'model' class we desired. Changing the cls_info.cls attribute led to another brick wall, the Property base class raising a RuntimeError("Property used in an unknown class") because the id of the model and the entity class didn't match. It almost seems like the design of Storm actively discourages this kind of dynamic mapping of property attributes to other classes.<br>
<br>We ended up using inheritance, with model classes inheriting from entity classes. This is less than ideal, especially because Reference and ReferenceSet don't bridge between the base class and the subclass. We had to recreate all the references in the model classes, and in many cases create model 'stub' classes where we would prefer to just use the entity classes.<br>
<br>SQLAlchemy has a feature for mapping 'table' object
attributes into arbitrary classes; is it reasonable to add the same kind of functionality to Storm?<br><br clear="all">Brad Allen<br>Architect, Integration Services<br>ZeOmega<br>3010 Gaylord Parkway, Suite 210<br>Frisco, TX 75034<br>
<a href="http://www.zeomega.com">www.zeomega.com</a><br>Proven. Progressive. Partner.<br>