Hello,<br><br>Has anyone implemented in Storm an useful approach to separating application logic from the __storm_table__ classes (which I usually call &#39;entity&#39; classes)? For purposes of this discussion, I&#39;ll use the word &#39;model&#39; 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 &#39;model&#39; 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 &#39;model&#39; class we desired. Changing the cls_info.cls attribute led to another brick wall, the Property base class raising a RuntimeError(&quot;Property used in an unknown class&quot;) because the id of the model and the entity class didn&#39;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&#39;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 &#39;stub&#39; classes where we would prefer to just use the entity classes.<br>
<br>SQLAlchemy has a feature for mapping &#39;table&#39; 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>