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
Steve, I have created a JIRA issue
(https://hibernate.onjira.com/browse/HHH-7090) and assigned it to you. Why do
you think that we
should not fix this in the upcoming release? I have also noticed that
auto-closing feature of SharedSessionBuilder does not work
as documented in JavaDoc. Please s
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
Grrr, of course that last line should have read:
Essentially replaces NamingStrategy#classToTableName
On Fri 17 Feb 2012 01:01:09 PM CST, Steve Ebersole wrote:
> As an example to start discussions, here is my first method proposal:
>
> public interface LogicalNamingStrategy {
> /**
> * Determin
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
Well these are the kind of details I was asking about with
transactionContext() :)
So transactionContext() is sharing too much of itself at the moment to
use it this way. Currently it just shares the entire
org.hibernate.engine.transaction.spi.TransactionContext from the
originating Session.
