From: <leg...@at...> - 2003-07-10 13:44:53
|
The following comment has been added to this issue: Author: Tom Sedge Created: Thu, 10 Jul 2003 8:43 AM Body: I forgot to say that the single-column discriminator is presumed by the persister/loader architecture via getDiscriminatorColumnName(). This is one of the reasons it is so difficult to extend this at the moment. What about a completely separate and extensible discriminator sub-system - would something like this be feasible? (I lack sufficient in-depth knowledge of Hibernate's sourcecode to judge this myself). --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-174 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-174 Summary: Allow multi-column discriminators and other discriminator improvements Type: Improvement Status: Unassigned Priority: Major Project: Hibernate2 Versions: 2.0.1 Assignee: Reporter: Tom Sedge Created: Thu, 10 Jul 2003 8:40 AM Updated: Thu, 10 Jul 2003 8:40 AM Environment: N/A Description: The extensible persister system in Hibernate is very nice and useful and custom discriminator types can be created via a custom Hibernate type and new persister. However, the structure of the discriminator is not wholly under the persister's control. Recently I've come across a number of situations where mapping legacy data models requires one of: 1. A joined-subclass discriminator where the discriminator in the parent table may be in more than one column (e.g. Column A not null implies Class A, Column B not null implies Class B). 2. A joined-subclass discriminator where the discriminator is not the primary key of the parent table. 3. A joined-subclass discriminator where force="true" can be applied. 4. Nesting a table-per-class-hierachy within joined-subclass (e.g. Table A contains parent class A, Table B joins to that table for class B and also contains Class C via a discriminator in Table B) & vice-versa. 5. Generating a discriminator from multiple columns via a general expression. As far as I can see (2) is not possible as there is no syntax support for this in the XML document (i.e. specify column in parent in <key> directive). (1) follows from (2) - requires specifying the column. (3) doesn't seem to be availale for joined-subclasses but is important since only some of the data in table may be needed. (4) looks completely ruled out by the DTD. (5) looks difficult, though a custom persister might be able to fudge it. What are the chances of Hibernate supporting any of the above? What is the level of difficulty involved in each one (I may be able to help). For the record, these seem to me to be reasonable requirements and would greatly ease working with difficult legacy data model - which in my experience are more common than greenfield sites. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |