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 th
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
Another subselect usage that does not currently appear to be supported
in annotations is for collection mappings. In hbm.xml you can specify
a subselect as the table for collections.
On Mon 20 Feb 2012 01:21:35 PM CST, Steve Ebersole wrote:
> Also, annotations currently do not support the full
Also, annotations currently do not support the full breadth of
subselect mappings available in hbm.xml.
For example, secondary tables in annotations cannot be defined using
these subselecty mappings while they can in hbm.xml. If its important,
it should be avilable everywhere no?
On Mon 20 Fe
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
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 / dele
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
