[hibernate-dev] subselect mappings

[Steve Ebersole]

As you know the old code is extremely hard to follow.  IIUC there 
really is not much of a difference, aside from loader being able to be 
callable, whereas subselect cannot.  IIUC they both infer a table name 
(if not specified explicitly)  and generate insert/update/delete 
statements.  AFAICT the both also allow explicit sql-insert, 
sql-update, etc.  Talking strictly from hbm side here.

Basically I am just pointing out a discrepancy between the allowable 
model from annotation/hbm.xml perspectives.  One of the benefits of 
this exercise is that we are able to go back and revisit this all and 
find such discrepancies and decide which approach is more logical.

Also, in general, its a good time to revisit all aspects of mapping to 
see what does not make sense.  As an example, currently if you specify 
subselect on a <join/> (secondary table) you HAVE TO give it a table 
name as well because the DTD names it as REQUIRED.  I have no idea why 
that is that way.  Logically, you should not have to name the table 
there.  Was it just an oversight when adding subselect support to 
<join/> to not change the DTD to IMPLIED instead?  Was it actually a 
decision to leave it REQUIRED?  And if so, why?


On Tue 21 Feb 2012 03:50:11 AM CST, Emmanuel Bernard wrote:
> What's the fundamental difference between a loader based entity and a subselect based entity assuming the entity is read-only. It seems that subselect lets you define which table it relies on and thus when the entity should be refreshed.
>
> Maybe ti would be worth converging here?
>
> On 20 févr. 2012, at 19:09, Steve Ebersole wrote:
>
>> for the "completeness" argument, the corollary to those others is actually loader, which is the ability to name a query to use for loading an entity/collection.
>>
>>
>> On Mon 20 Feb 2012 12:57:36 PM CST, Emmanuel Bernard wrote:
>>> I find the second reason important. In some organizations, the idea of developers owning a schema especially on legacy database is harder than climbing the Himalaya bare foot.
>>> Having access to the subselect views helps.
>>>
>>> I also like it for completeness since we can override insert / update / delete statements.
>>>
>>> On 20 févr. 2012, at 18:52, Steve Ebersole wrote:
>>>
>>>> subselects are a feature that was originally put in place to support
>>>> databases without view support and/or application developers which did
>>>> not have access to create views on their target database.
>>>>
>>>> I am contemplating whether we want to continue to support this.
>>>>
>>>> At this time I all real databases out there support views.  Anyone know
>>>> of any that do not?
>>>>
>>>> I am not inclined to leave the feature in place just for the second
>>>> reason.  They could always define the view in a schema in which they do
>>>> have access to create views.
>>>>
>>>> Thoughts?
>>>>
>>>> -- 
>>>> steve at hibernate.org
>>>> http://hibernate.org
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> -- 
>> steve at hibernate.org
>> http://hibernate.org
>

-- 
steve at hibernate.org
http://hibernate.org