hibernate-devel

[Hibernate] Normalized table mappings

[Gavin K. <ga...@ap...>]

I now have what I believe is a fully-working implementation of the
table-per-subclass mapping strategy. It would be really cool if people would
try it out. I plan to release this new feature as Hibernate 1.2 beta. The
only missing thing is support for databases without ANSI-style OUTER JOIN
and CASE. So we'll still need to do a bit more work to get it working on
Oracle.

At this point I'm deprecating hibernate-mapping.dtd and documenting
hibernate-mapping-1.1.dtd as the preferred mapping document DTD. Theres a
couple of non-compatible changes, but nothing that should cause headaches.

Re: [Hibernate] Normalized table mappings

[Gavin K. <ga...@ap...>]

> Currently I have another problem with the OuterJoinGenerator:
> The SQL created by the constructor of EntityLoader is always using ' LEFT
OUTER JOIN'
> even if I use the OracleOuterJoinGenerator.  I've added the a log
statement in the constructor
> and it tells me that the sql 'select .... from foo left outer join bar on
....' was created with
> an OracleOuterJoinGenerator???!!!?

I'm not following properly.....

MultiTableEntityPersister produces some SQL with "left outer join"
hardcoded, as you noted. Some refactoring is needed to fix this. But I'm
pretty sure the SQL generation for outerjoin fetching never produces "LEFT
OUTER JOIN" when the SQL dialect is set for Oracle. Surely you aren't seeing
this when using EntityPersister?

> In the documentation you mentioned clustering capabilities, but I haven't
found any
> code about it.

The reason Hibernate is safe for use in a cluster is that by default caching
is done at the transaction-level. We do not support the use of
cross-transaction caching in a clustered environment, though Christian
Muenier might be releasing some code for this is a seperate project.

Re: [Hibernate] Normalized table mappings

[Wolfgang J. <w....@mi...>]

On Wednesday 06 November 2002 15:19, Gavin King wrote:
> > Currently I have another problem with the OuterJoinGenerator:
> > The SQL created by the constructor of EntityLoader is always using ' =
LEFT
> > OUTER JOIN'
>
> > even if I use the OracleOuterJoinGenerator.  I've added the a log
> > statement in the constructor
>
> > and it tells me that the sql 'select .... from foo left outer join ba=
r on
> >....' was created withan OracleOuterJoinGenerator???!!!?
>
> I'm not following properly.....
>
> MultiTableEntityPersister produces some SQL with "left outer join"
> hardcoded, as you noted. Some refactoring is needed to fix this. But I'=
m
> pretty sure the SQL generation for outerjoin fetching never produces "L=
EFT
> OUTER JOIN" when the SQL dialect is set for Oracle. Surely you aren't
> seeing this when using EntityPersister?

I've added the following logging code to the constructor of EntityLoader:
log.info("Built select=3D" + sql + " via "
+ outerJoinGenerator.getClass().getName());

and get the following while running MultiTableTest:
=2E...
    [junit] Nov 6, 2002 3:56:24 PM cirrus.hibernate.sql.Dialect <init>
    [junit] INFO: Using dialect: cirrus.hibernate.sql.OracleDialect
=2E...
    [junit] Nov 6, 2002 3:56:24 PM cirrus.hibernate.loader.OuterJoinLoade=
r=20
<init>
    [junit] INFO: Using JoinGenerator=20
cirrus.hibernate.loader.OracleOuterJoinGenerator
    [junit] Nov 6, 2002 3:56:24 PM cirrus.hibernate.loader.EntityLoader <=
init>
    [junit] INFO: Built select=3DSELECT rootc0.id_ AS id_, rootc01.amount=
 as=20
amount10, rootc02.extraProp as extraProp8, rootc02.other2 as other29,=20
rootc0.count_ as count_0, rootc0.name as name1, rootc0.address as address=
2,=20
rootc0.date_ as date_3 FROM rootclass rootc0  left outer join submulti=20
rootc01 on rootc0.id_=3Drootc01.sid left outer join nuthasubclass rootc02=
 on=20
rootc0.id_=3Drootc02.sid WHERE rootc0.id_ =3D ? via=20
cirrus.hibernate.loader.OracleOuterJoinGenerator
    [junit] Nov 6, 2002 3:56:24 PM=20
cirrus.hibernate.persister.MultiTableEntityPersister generateSelectString
    [junit] INFO: Using select=3Dselect rootclass.id_, submulti.amount as=
=20
amount10, nuthasubclass.extraProp as extraProp8, nuthasubclass.other2 as=20
other29, rootclass.count_ as count_0, rootclass.name as name1,=20
rootclass.address as address2, rootclass.date_ as date_3 from rootclass,=20
submulti, nuthasubclass where rootclass.id_ =3D ? and=20
rootclass.id_=3Dsubmulti.sid (+) and rootclass.id_=3Dnuthasubclass.sid (+=
)
=2E....

Maybe the SQL-code from EntityLoader is never reached, but I have no clue=
,=20
where the sql-String from EntityLoader is comming from.=20


CU
--=20
Wolfgang Jung, Softwareentwickler
Micromata_Objects GmbH                 Tel: +49 561 316793-0
Marie-Calm Strasse 1, D-34131 Kassel   Fax: +49 561 316793-11
mailto:W....@mi...             http://www.micromata.de

Re: [Hibernate] Normalized table mappings

[Gavin K. <ga...@ap...>]

Oh yeah, I expect this. MultiTableEntityPersister does some SQL generation
itself thats not (yet) aware of Oracle-style outerjoins. Just do a search
for "left outer join". This generated SQL is probably not being used if
outerjoin fetching is enabled.

I just noticed that currently MultiTableEntityPersister doesn't support
loadWithLock(). So I guess thats also on the TODO list.

----- Original Message -----
From: "Wolfgang Jung" <w....@mi...>
To: "Gavin King" <ga...@ap...>
Cc: "hibernate list" <hib...@li...>
Sent: Thursday, November 07, 2002 2:03 AM
Subject: Re: [Hibernate] Normalized table mappings


> On Wednesday 06 November 2002 15:19, Gavin King wrote:
> > > Currently I have another problem with the OuterJoinGenerator:
> > > The SQL created by the constructor of EntityLoader is always using '
LEFT
> > > OUTER JOIN'
> >
> > > even if I use the OracleOuterJoinGenerator.  I've added the a log
> > > statement in the constructor
> >
> > > and it tells me that the sql 'select .... from foo left outer join bar
on
> > >....' was created withan OracleOuterJoinGenerator???!!!?
> >
> > I'm not following properly.....
> >
> > MultiTableEntityPersister produces some SQL with "left outer join"
> > hardcoded, as you noted. Some refactoring is needed to fix this. But I'm
> > pretty sure the SQL generation for outerjoin fetching never produces
"LEFT
> > OUTER JOIN" when the SQL dialect is set for Oracle. Surely you aren't
> > seeing this when using EntityPersister?
>
> I've added the following logging code to the constructor of EntityLoader:
> log.info("Built select=" + sql + " via "
> + outerJoinGenerator.getClass().getName());
>
> and get the following while running MultiTableTest:
> ....
>     [junit] Nov 6, 2002 3:56:24 PM cirrus.hibernate.sql.Dialect <init>
>     [junit] INFO: Using dialect: cirrus.hibernate.sql.OracleDialect
> ....
>     [junit] Nov 6, 2002 3:56:24 PM cirrus.hibernate.loader.OuterJoinLoader
> <init>
>     [junit] INFO: Using JoinGenerator
> cirrus.hibernate.loader.OracleOuterJoinGenerator
>     [junit] Nov 6, 2002 3:56:24 PM cirrus.hibernate.loader.EntityLoader
<init>
>     [junit] INFO: Built select=SELECT rootc0.id_ AS id_, rootc01.amount as
> amount10, rootc02.extraProp as extraProp8, rootc02.other2 as other29,
> rootc0.count_ as count_0, rootc0.name as name1, rootc0.address as
address2,
> rootc0.date_ as date_3 FROM rootclass rootc0  left outer join submulti
> rootc01 on rootc0.id_=rootc01.sid left outer join nuthasubclass rootc02 on
> rootc0.id_=rootc02.sid WHERE rootc0.id_ = ? via
> cirrus.hibernate.loader.OracleOuterJoinGenerator
>     [junit] Nov 6, 2002 3:56:24 PM
> cirrus.hibernate.persister.MultiTableEntityPersister generateSelectString
>     [junit] INFO: Using select=select rootclass.id_, submulti.amount as
> amount10, nuthasubclass.extraProp as extraProp8, nuthasubclass.other2 as
> other29, rootclass.count_ as count_0, rootclass.name as name1,
> rootclass.address as address2, rootclass.date_ as date_3 from rootclass,
> submulti, nuthasubclass where rootclass.id_ = ? and
> rootclass.id_=submulti.sid (+) and rootclass.id_=nuthasubclass.sid (+)
> .....
>
> Maybe the SQL-code from EntityLoader is never reached, but I have no clue,
> where the sql-String from EntityLoader is comming from.
>
>
> CU
> --
> Wolfgang Jung, Softwareentwickler
> Micromata_Objects GmbH                 Tel: +49 561 316793-0
> Marie-Calm Strasse 1, D-34131 Kassel   Fax: +49 561 316793-11
> mailto:W....@mi...             http://www.micromata.de