[hibernate-dev] subselect mappings
steve at hibernate.org
Tue Feb 21 14:51:22 EST 2012
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.
>>>> steve at hibernate.org
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>> steve at hibernate.org
steve at hibernate.org
More information about the hibernate-dev