Clute, Andrew wrote:
That would work, I guess, though I'd rather put the class name next to the foreignkey:That's what I assumed, and was afraid of.
I think I can get around it temporarily by actually creating a composite field that contains the classname and the PK in the same field (i.e. "foo.bar.CatalogItem:12345"), and then creating a custom Conversion that will take that string and instantiate the object.
Now, is there any technical reason why there isn't a strategy to map a class that has a reference to an interface-backed class where the concrete classes are not mapped in the same table? It would seem to me, that such a feature could be implemented pretty straight-forward in the current architecture (and I would be willing to take that on), but I want to make sure I understand all of the ramifications of why this isn't done at this time (feature never implemented?, won't work with what we currently have?, etc.
One staight-forward approach would to modify the repostiroy_user.xml definitions to allow the following type of mapping:
<reference-descriptor name="interfaceItem" class-name-field-ref="interfaceClassName" > <foreignkey field-ref="interfaceGuid"/> </reference-descriptor>
<field-descriptor name="interfaceClassName" column="interface_class_name" jdbc-type="VARCHAR" /> <field-descriptor name="interfaceGuid" column="interface_guid" jdbc-type="VARCHAR" access="anonymous" />
<reference-descriptor
name="interfaceItem"
>
<concreteClassName field-ref="interfaceClassName"/>
<foreignkey field-ref="interfaceGuid"/>
</reference-descriptor>IMO this concept should be extended to collections as well (inverse-concreteClassName) to get rid of the hard-coded 'ojbConcreteClass' stuff. Might be a good use of anonymous fields, too.
And sure, if you want to have a go at it, by all means go ahead !
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
