Regarding Alex Bacon's "Major issue with Hibernate Filters" circa Sept 11, 2006...
by Edmund Grossenbacher
I have a similar situation to what Alex Bacon described in his "Major
issue with Hibernate Filters" thread in September, and I'm wondering if
there was ever a palatable resolution.
The basic notion is that I have an object graph consisting of
relationships of varying multiplicity. For various reasons I wish to
introduce "effective dates" into the database. The documented Filter
example of Employee and Department pretty much illustrates the idea.
Lets say that at any given time, an Employee …
[View More]belongs to one Department,
and a Department has multiple employees (so Department has a one-to-many
bidirectional relationship with Employee.) Employee contains a foreign
key back to Department, which is the canonical way to represent
one-to-many relationships in the database - by putting a foreign key on
the "many" side.
Over time, an employee can move between departments, so without
considering time the relationship between Employee and Department is
many-to-many. Note that I don't actually need a many-to-many join table
here: Employee still contains an FK back to Department, and a given
Employee ID now appears multiple times in the Employee table with
non-overlapping "effective date" time intervals. At particular point in
time, only ONE Employee row is effective.
I only care about the relationships that exist at particular points in
time. Therefore, I wish to apply a Filter that *I know* will always
produce a one-to-many relationship between Department and Employee.
Steve's comment suggests that this is a misapplication of "Filter" -
because to assume that Filter will slice the one-to-many relationship
(at a single point in time) out of the many-to-many relationship that is
actually stored in the database would be using Filters to change
multiplicity, and that is apparently NOT the intent.
Fine: so forget Filters. Is there another way to get this same effect?
I know one way: I can create views that reproduce the "full" object
graph at each point in time that is of interest. Those views will have
the correct one-to-many (or one-to-one) relationships in them. I could
then map the views with Hibernate. The downside here is, I *also* need
to map the "current time" of the real underlying tables, so that I can
manipulate them to write updates. That means I need essentially two
mappings of the same set of objects, which sounds like more work.
The "Filter" concept seems so close to what I want... If Entity-level
Filters are ALWAYS applied to generated SQL it seems like this would
work, at least if I always enable the Filter before doing any operations
involving timesliced entities. If autoenabled Filters were present (per
ANN-433) it seems like the solution would be even sweeter.
Has anyone had REAL experience using timeslicing (effective dates, etc)
in the database and mapping the single-point-in-time results with
Hibernate? I've seen this pattern in several databases in my career -
although typically it seems to appear in warehouse environments more
than in production databases..;
-ed
[View Less]
18 years, 1 month
RE: [NHibernate-development] [hibernate-dev] Connection release modes
by Steve Ebersole
How did that lead to a discussion of connection release modes ;)
Mmm, I'd have to look through the code; *but* a load & lock operation
makes no sense in an auto-commit scenario; so I'd assume it has to do
with that...
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Sergey
Koshcheyev
Sent: Wednesday, December 13, 2006 11:11 AM
To: the NHibernate development list
Cc: hibernate
Subject: Re: [NHibernate-…
[View More]development] [hibernate-dev] Connection release
modes
Steve Ebersole wrote:
> I don't understand the statement about "auto-commit mode connection
> release". The idea with the implied auto-commit connection release
mode
> is that in the case of auto-commit transaction control, there is
really
> no need to have the same connection for each operation as long as we
are
> not batching and not generally holding open JDBC resources. What
makes
> you say it appears to happen for just a few operations?
I guess I worded that badly. To put it in source code terms: in
SessionImpl.get(String entityName, Serializable id) there is a call to
SessionImpl.afterOperation. There is no such call in
SessionImpl.get(String entityName, Serializable id, LockMode lockMode).
Is this a mistake or is the call not needed in the second case for some
reason?
Sergey
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[View Less]
18 years, 1 month
RE: [hibernate-dev] Connection release modes
by Steve Ebersole
I don't understand the statement about "auto-commit mode connection
release". The idea with the implied auto-commit connection release mode
is that in the case of auto-commit transaction control, there is really
no need to have the same connection for each operation as long as we are
not batching and not generally holding open JDBC resources. What makes
you say it appears to happen for just a few operations?
"With a Java transaction manager we have to give back the connection
after every SQL …
[View More]statement" => That's not completely true. The reason we
introduced this behavior was to circumvent "resource containment checks"
in environments which do such things (JBoss, WebLogic and WebSphere app
servers for example). "resource containment who-whats"? ;) Well there
is a usage pattern which used to cause Hibernate users problems in such
environments. Consider the case of an EJB application using Hibernate
where the EJBs call one another; something like:
SessionBeanA {
public void doSomething() {
Session s = ...;
SessionBeanB b = ...;
b.doSomethingElse();
}
}
SessionBeanB {
public void doSomethingElse() {
Session s = ...;
s.load( MyEntity.class, "myKey" );
// do some more work and return
}
}
Pretty innocuous, right? The problem lies in the fact that the Session
did not actually obtain a JDBC connection until the execution of
SessionBeanB.doSomethingElse() since it delays getting a connection
until needed. The problem, from the perspective of environments which
do perform resource containment checks, is that we just leaked a
resource... the connection! The connection was retrieved from the DS
during the execution of SessionBeanB.doSomethingElse(), but is not
released by the time SessionBeanB.doSomethingElse() completes execution.
And just to round out the discussion, I do not know how this works in
the .Net corollaries, but after_transaction should not be used in the
case of some form of managed transaction and transacted datasources.
Doing so would cause Hibernate to try and release its connection handle
during the Synchronization.afterCompletion callback, which is
disallowed.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Christian
Bauer
Sent: Wednesday, December 13, 2006 5:56 AM
To: the NHibernate development list; hibernate
Subject: [hibernate-dev] Connection release modes
Bringing the two lists together for this thread.
On Dec 13, 2006, at 12:01 PM, Sergey Koshcheyev wrote:
> Christian Bauer wrote:
>> Maybe NHibernate only needs two modes. NHibernate probably only need
>> to release either after transaction (also auto-committed) and when
>> the Session is closed.
> By the way, after reading the Hibernate source, it looks to me that
> auto-commit mode connection release only happens for a few
> operations on
> the session, not all of them (for example refresh, lock, get with
> LockMode seem to be exempt). Was this intended (why?) or was this an
> oversight?
>
>> With a Java transaction manager we have to
>> give back the connection after every SQL statement. The service
>> guarantees that we will get back "the same" connection inside the
>> same transaction, for the next SQL statement. Is that common in .NET
>> environments?
>>
> As far as I know, it is not.
>
> Sergey
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[View Less]
18 years, 1 month
RE: Hibernate test suite
by Steve Ebersole
Perhaps the custom file selector was causing some problems. I did add a
path element to the definition of the file selector so that it had
access to the jar.driver.
-----Original Message-----
From: Aleksandar Kostadinov [mailto:akostadinov@jboss.com]
Sent: Wednesday, December 13, 2006 9:52 AM
To: Steve Ebersole
Cc: hibernate-dev(a)lists.jboss.org
Subject: Re: Hibernate test suite
It is very strange that copying the file to the lib dir makes things
work. I tried to replace where in build.xml …
[View More]jar.driver is set to hsql,
but that didn't worked also.
Any ideas?
Aleksandar Kostadinov wrote:
> Yeah, I see that the problem is not finding the jdbc driver. I meant
> that all other databases tests fail with a new reason, but the same
> for all of them.
> I asked you if there is a change in how hibernate searches for it.
> Cruisecontrol invokes ant with the following pratameters:
> -Djar.driver=${driver.jar}
> -Dhibernate.test.validatefailureexpected=true
> -lib lib
>
> Here driver.jar is the jdbc driver location. Is there some change that
> prevents this from working and is it possible to make this work.
>
> Steve Ebersole wrote:
>
>>No the failures are different. Previously we were getting NPE; now
CCE.
>>
>>The tests run fine for me in my IDE. The only way I have been able to
>>reproduce such a CCE is for the JDBC driver to be unavailable when the
>>junit task starts up. This causes the constructor of one of the test
>>classes to fail, which JUnit handles by creating a "stand-in" test
case
>>of type an inner type as defined in the TestSuite.warning() method. I
>>have added extra protections to allow non-FunctionalTestCase instance
to
>>be handled by the FunctionalTestClassTestSuite which I will be
checking
>>in soon.
>>
>>In the meantime, I would assume this indicates a problem with the CC
>>test runs not being able to find the drivers. Hard to tell without
the
>>stack trace and error log...
>>
>>
>>-----Original Message-----
>>From: Aleksandar Kostadinov [mailto:akostadinov@jboss.org]
>>Sent: Wednesday, December 13, 2006 3:30 AM
>>To: Steve Ebersole
>>Cc: hibernate-dev(a)lists.jboss.org
>>Subject: Re: Hibernate test suite
>>
>>Only hsql tests work.
>>
>>Other databases tests fail with the same reason.
>>
>>Is there a change in the way testsuite should be ran? How to set jdbc
>>driver? Properties file changes?
>>
>>Steve Ebersole wrote:
>>
>>
>>
>>>I am just now checking in the reorganization of the Hibernate test
>>>
>>>
>>suite
>>
>>
>>>I have been working on for the last few days.
>>>
>>>The main piece is the addition of the org.hibernate.junit package in
>>>
>>>
>>the
>>
>>
>>>test source directory. Specifically, tests in the test suite now
have
>>>two well defined flavors:
>>>1) org.hibernate.junit.UnitTestCase
>>>2) org.hibernate.junit.functional.FunctionalTestCase
>>>
>>>The vast majority of the Hibernate test suite falls into the later
>>>category...
>>>
>>>Also, a new custom TestSuite subclass was introduced for
>>>FunctionalTestCase classes
>>>(org.hibernate.junit.functional.FunctionalTestClassTestSuite).
>>>FunctionalTestCase classes should use this custom test suite from
their
>>>suite() method. The main reason for this set up is to allow better
>>>sharing of a SessionFactory between TestCase methods. Previously,
the
>>>org.hibernate.test.TestCase class had this responsibility. The
>>>
>>>
>>problems
>>
>>
>>>being that it did not have visibility into when the "run" completed.
>>>
>>>
>>So
>>
>>
>>>it just left the schema for the last run test hanging around. This
new
>>>set up makes sure that does not happen, because it is the test suite
>>>which is responsible for building/closing the SessionFactory.
>>>FunctionalTestCase does build a SessionFactory if one is not injected
>>>into it by FunctionalTestClassTestSuite (or some other source). It
>>>considers this a "locally managed" SessionFactory which will get
closed
>>>after the completion of the test method; this is for running a single
>>>method in an IDE.
>>>
>>>Anyway, the test suite should start working again ;)
>>>
>>>
>>>
>>>
>>>
[View Less]
18 years, 1 month
RE: Hibernate test suite
by Steve Ebersole
No the failures are different. Previously we were getting NPE; now CCE.
The tests run fine for me in my IDE. The only way I have been able to
reproduce such a CCE is for the JDBC driver to be unavailable when the
junit task starts up. This causes the constructor of one of the test
classes to fail, which JUnit handles by creating a "stand-in" test case
of type an inner type as defined in the TestSuite.warning() method. I
have added extra protections to allow non-FunctionalTestCase instance …
[View More]to
be handled by the FunctionalTestClassTestSuite which I will be checking
in soon.
In the meantime, I would assume this indicates a problem with the CC
test runs not being able to find the drivers. Hard to tell without the
stack trace and error log...
-----Original Message-----
From: Aleksandar Kostadinov [mailto:akostadinov@jboss.org]
Sent: Wednesday, December 13, 2006 3:30 AM
To: Steve Ebersole
Cc: hibernate-dev(a)lists.jboss.org
Subject: Re: Hibernate test suite
Only hsql tests work.
Other databases tests fail with the same reason.
Is there a change in the way testsuite should be ran? How to set jdbc
driver? Properties file changes?
Steve Ebersole wrote:
>I am just now checking in the reorganization of the Hibernate test
suite
>I have been working on for the last few days.
>
>The main piece is the addition of the org.hibernate.junit package in
the
>test source directory. Specifically, tests in the test suite now have
>two well defined flavors:
>1) org.hibernate.junit.UnitTestCase
>2) org.hibernate.junit.functional.FunctionalTestCase
>
>The vast majority of the Hibernate test suite falls into the later
>category...
>
>Also, a new custom TestSuite subclass was introduced for
>FunctionalTestCase classes
>(org.hibernate.junit.functional.FunctionalTestClassTestSuite).
>FunctionalTestCase classes should use this custom test suite from their
>suite() method. The main reason for this set up is to allow better
>sharing of a SessionFactory between TestCase methods. Previously, the
>org.hibernate.test.TestCase class had this responsibility. The
problems
>being that it did not have visibility into when the "run" completed.
So
>it just left the schema for the last run test hanging around. This new
>set up makes sure that does not happen, because it is the test suite
>which is responsible for building/closing the SessionFactory.
>FunctionalTestCase does build a SessionFactory if one is not injected
>into it by FunctionalTestClassTestSuite (or some other source). It
>considers this a "locally managed" SessionFactory which will get closed
>after the completion of the test method; this is for running a single
>method in an IDE.
>
>Anyway, the test suite should start working again ;)
>
>
>
[View Less]
18 years, 1 month
RE: Hibernate test suite
by Steve Ebersole
I did not touch the build script at all as part of that previous
commit...
________________________________________
From: Aleksandar Kostadinov [mailto:akostadinov@jboss.org]
Sent: Wednesday, December 13, 2006 8:37 AM
To: Steve Ebersole
Cc: hibernate-dev(a)lists.jboss.org
Subject: Re: Hibernate test suite
Yeah, I see that the problem is not finding the jdbc driver. I meant
that all other databases tests fail with a new reason, but the same for
all of them.
I asked you if there is a change in …
[View More]how hibernate searches for it.
Cruisecontrol invokes ant with the following pratameters:
-Djar.driver=${driver.jar}
-Dhibernate.test.validatefailureexpected=true
-lib lib
Here driver.jar is the jdbc driver location. Is there some change that
prevents this from working and is it possible to make this work.
Steve Ebersole wrote:
No the failures are different. Previously we were getting NPE; now CCE.
The tests run fine for me in my IDE. The only way I have been able to
reproduce such a CCE is for the JDBC driver to be unavailable when the
junit task starts up. This causes the constructor of one of the test
classes to fail, which JUnit handles by creating a "stand-in" test case
of type an inner type as defined in the TestSuite.warning() method. I
have added extra protections to allow non-FunctionalTestCase instance to
be handled by the FunctionalTestClassTestSuite which I will be checking
in soon.
In the meantime, I would assume this indicates a problem with the CC
test runs not being able to find the drivers. Hard to tell without the
stack trace and error log...
-----Original Message-----
From: Aleksandar Kostadinov [mailto:akostadinov@jboss.org]
Sent: Wednesday, December 13, 2006 3:30 AM
To: Steve Ebersole
Cc: hibernate-dev(a)lists.jboss.org
Subject: Re: Hibernate test suite
Only hsql tests work.
Other databases tests fail with the same reason.
Is there a change in the way testsuite should be ran? How to set jdbc
driver? Properties file changes?
Steve Ebersole wrote:
I am just now checking in the reorganization of the Hibernate test
suite
I have been working on for the last few days.
The main piece is the addition of the org.hibernate.junit package in
the
test source directory. Specifically, tests in the test suite now have
two well defined flavors:
1) org.hibernate.junit.UnitTestCase
2) org.hibernate.junit.functional.FunctionalTestCase
The vast majority of the Hibernate test suite falls into the later
category...
Also, a new custom TestSuite subclass was introduced for
FunctionalTestCase classes
(org.hibernate.junit.functional.FunctionalTestClassTestSuite).
FunctionalTestCase classes should use this custom test suite from their
suite() method. The main reason for this set up is to allow better
sharing of a SessionFactory between TestCase methods. Previously, the
org.hibernate.test.TestCase class had this responsibility. The
problems
being that it did not have visibility into when the "run" completed.
So
it just left the schema for the last run test hanging around. This new
set up makes sure that does not happen, because it is the test suite
which is responsible for building/closing the SessionFactory.
FunctionalTestCase does build a SessionFactory if one is not injected
into it by FunctionalTestClassTestSuite (or some other source). It
considers this a "locally managed" SessionFactory which will get closed
after the completion of the test method; this is for running a single
method in an IDE.
Anyway, the test suite should start working again ;)
[View Less]
18 years, 1 month
Connection release modes
by Christian Bauer
Bringing the two lists together for this thread.
On Dec 13, 2006, at 12:01 PM, Sergey Koshcheyev wrote:
> Christian Bauer wrote:
>> Maybe NHibernate only needs two modes. NHibernate probably only need
>> to release either after transaction (also auto-committed) and when
>> the Session is closed.
> By the way, after reading the Hibernate source, it looks to me that
> auto-commit mode connection release only happens for a few
> operations on
> the session, not …
[View More]all of them (for example refresh, lock, get with
> LockMode seem to be exempt). Was this intended (why?) or was this an
> oversight?
>
>> With a Java transaction manager we have to
>> give back the connection after every SQL statement. The service
>> guarantees that we will get back "the same" connection inside the
>> same transaction, for the next SQL statement. Is that common in .NET
>> environments?
>>
> As far as I know, it is not.
>
> Sergey
[View Less]
18 years, 1 month