Re: [hibernate-dev] Help with Hibernate OGM-401
by Emmanuel Bernard
Hello,
Look at BuiltInTypeTest and Bookmark. Bookmark hosts all of our built-in types.
We usually don’t do unit tests in the strictest sense. We prefer to run the chain from top to bottom in what people call integration tests.
About
org.hibernate.ogm.test.type.CustomDateType
org.hibernate.ogm.test.type.ExplodingType
org.hibernate.ogm.test.type.OverridingTypeDialect
org.hibernate.ogm.test.type.Poem
They are testing that a dialect can override types. It is indeed a test and not part of the core engine.
Emmanuel
> On 16 Dec 2014, at 13:22, Ajay Bhat <a.ajay.bhat(a)gmail.com> wrote:
>
> Hi Emmanuel,
>
> I was working on supporting Short and Float datatypes for Hibernate OGM (issue 401) and I noticed that there are no unit tests for TypeTranslatorImpl [1]. Where should I look for it, if a test does exist? Shall I add a unit test for that?
>
> Also I noticed that some classes are present in the "test" package, rather than "main".[2] Could you pls explain why this was done?
> [1] org/hibernate/ogm/type/impl/TypeTranslatorImpl.java
> [2]
> org.hibernate.ogm.test.type.CustomDateType
> org.hibernate.ogm.test.type.ExplodingType
> org.hibernate.ogm.test.type.OverridingTypeDialect
> org.hibernate.ogm.test.type.Poem
>
> https://hibernate.atlassian.net/browse/OGM-401 <https://hibernate.atlassian.net/browse/OGM-401>
>
> Thanks,
> Ajay
10 years, 10 months
Security: Requiring Maven version 3.2.3 in our (maven based) builds
by Sanne Grinovero
Some weeks ago there was quite a fuss about the security implications
of Maven downloading all those binary jars over HTTP rather than over
HTTPS.
That was fixed and now all mirrors support HTTPS and this latest Maven
version uses secure connections by default.
I'm usually careful in upgrading Maven, but I've been using this
version for a while now and it worked fine - including during release
processes - and also it's the version used by CI since some weeks on
some jobs (didn't update them all - CI can test with various different
versions).
I think we should make this version (at least) a requirement for builds. WDYT?
Sanne
10 years, 10 months
Re: [hibernate-dev] Mapping defaults for @OneToOne
by Steve Ebersole
Well, we don't want to rely on that. That is meant to be across all
features. I think we want to look at this for this specific feature.
That's kind of the design of Dialect overall.
On Dec 11, 2014 5:56 PM, "Gail Badner" <gbadner(a)redhat.com> wrote:
> Yes, that makes good sense. I see the info is available via
> DatabaseMetaData.supportsANSI92EntryLevelSQL(),
> supportsANSI92IntermediateSQL(), and supportsANSI92FullSQL().
>
> Hmm, what if DatabaseMetaData is not available. Do we assume ENTRY?
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve(a)hibernate.org>
> > To: "Gail Badner" <gbadner(a)redhat.com>, "hibernate-dev" <
> hibernate-dev(a)lists.jboss.org>
> > Sent: Thursday, December 11, 2014 1:41:09 PM
> > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne
> >
> > Are you asking me what "leveing rules" are? ANSI SQL defines a number of
> > levels of conformance: entry, intermediate and full. These leveling
> rules
> > describe additional rules/restrictions/limitations for certain
> conformance
> > level.
> >
> > Taking a step back... a unique constraint says that the column(s) listed
> in
> > the constraint specification must contain unique values. Well how do we
> > know values are unique? We know because they are not equal to one
> > another. And how does ANSI SQL define equality wrt NULL? It says that
> > NULLs are never equal. So how can they violate a unique constraint?
> >
> > *If* we are to make any change here, I think what might be worthwhile is
> to
> > have the Dialect indicate what level of conformance it suports wrt unique
> > constraints. If the Dialect reports FULL or INTERMEDIATE support, then
> we
> > would support building a UK on nullable columns; if it reports ENTRY, we
> > would not.
> > On Dec 11, 2014 2:54 PM, "Gail Badner" <gbadner(a)redhat.com> wrote:
> >
> > > I check several dialects (can't remember exactly which ones)
> > >
> > > I see the following in
> > > http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt in 11.7
> <unique
> > > constraint definition>:
> > >
> > > Leveling Rules
> > >
> > > 1) The following restrictions apply for Intermediate SQL:
> > >
> > > None.
> > >
> > > 2) The following restrictions apply for Entry SQL in addition
> to
> > > any Intermediate SQL restrictions:
> > >
> > > a) If PRIMARY KEY or UNIQUE is specified, then the <column
> > > defi-
> > > nition> for each column whose <column name> is in the
> <unique
> > > column list> shall specify NOT NULL.
> > >
> > > To be honest, I don't know how these leveling rules are supposed to
> work.
> > > Do you?
> > >
> > > ----- Original Message -----
> > > > From: "Steve Ebersole" <steve(a)hibernate.org>
> > > > To: "Gail Badner" <gbadner(a)redhat.com>
> > > > Sent: Wednesday, December 10, 2014 5:07:37 PM
> > > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne
> > > >
> > > > The point is the same. ANSI SQL even states that unique keys should
> > > > disallow duplicate *non null* values but allow multiple rows with
> null.
> > > > Again, it just makes sense; null is *not* a value.
> > > >
> > > > Does some database not support that? Yeah ok maybe
> > > > On Dec 10, 2014 2:46 PM, "Gail Badner" <gbadner(a)redhat.com> wrote:
> > > >
> > > > > The problem here is not that the FK has a null value. The problem
> is
> > > that
> > > > > the FK column has a unique constraint. It's the unique constraint
> that
> > > > > throws an exception when there is more than one null value for that
> > > column.
> > > > >
> > > > > I chatted with Emmanuel about this topic:
> > > > >
> > > > > (01:26:57 PM) emmanuel: gbadner: BTW if that's about your email on
> -dev
> > > > > and if for real DBs consider null as a unique value, then I think
> > > Hibernate
> > > > > doe sthr right thing by not enforcing
> > > > > (01:26:59 PM) emmanuel: it
> > > > >
> > > > > (01:37:13 PM) gbadner: emmanuel, what does that mean wrt to the
> spec?
> > > > > (01:37:37 PM) gbadner: is hibernate non-compliant, but does the
> right
> > > > > thing?
> > > > > (01:37:39 PM) emmanuel: the spec is not the gospel
> > > > > (01:38:10 PM) gbadner: there is an inconsistency between hbm.xml
> and
> > > > > annotations
> > > > > (01:39:02 PM) gbadner: the reason I care is that I have a fix for
> an
> > > issue
> > > > > that works for annotations, but not hbm.xml
> > > > > (01:39:34 PM) gbadner: the reason it works for annotations is
> because
> > > > > there is no unique constraint when the @OneToOne is optional
> > > > > (01:41:45 PM) gbadner: what *should* hibernate do when hbm.xml has:
> > > > > not-null="false" unique="true" ?
> > > > > (01:42:21 PM) emmanuel: hbm has always philosophically been close
> to
> > > the
> > > > > physicla model
> > > > > (01:42:22 PM) gbadner: currently, hibernate goes ahead and creates
> the
> > > > > unique constraint
> > > > > (01:42:34 PM) emmanuel: so applying the unique constraint would be
> > > what I
> > > > > expect
> > > > > (01:43:25 PM) gbadner: but should hibernate also override with
> > > > > not-null="true" when unique="true"?
> > > > > (01:44:03 PM) gbadner: ^^^ and give a warning?
> > > > > (01:45:30 PM) emmanuel: gbadner: I don't think I would expect that
> from
> > > > > hbm, no
> > > > > (01:45:49 PM) emmanuel: afterall it might be applicable for some
> > > database
> > > > > (01:45:50 PM) emmanuel: s
> > > > > (01:46:03 PM) emmanuel: (but even if it was not, hbm is explicit
> as I
> > > > > mentioned)
> > > > > (01:46:57 PM) gbadner: hibernate *knows* when a column is
> > > non-nullable; I
> > > > > don't think it knows when there is a unique constraint
> > > > > (01:47:26 PM) gbadner: well, I suppose the best Hibernate can do is
> > > just
> > > > > assume there is a unique constraint
> > > > >
> > > > > My fix for HHH-9091 (really it's a hack) is not acceptable because
> it
> > > will
> > > > > cause regressions for hbm.xml mappings.
> > > > >
> > > > > HHH-9091 is caused by HHH-6484. HHH-6484 made a change to execute
> > > orphan
> > > > > deletes before anything else, which causes a regression as
> illustrated
> > > in
> > > > >
> > >
> https://github.com/hibernate/hibernate-orm/commit/c068b6f70c84476db7a0cd2...
> > > > > .
> > > > >
> > > > > At the very least, orphan-deletes must be executed in the proper
> > > order. I
> > > > > have to think more about whether are other dependencies that need
> to be
> > > > > taken into account.
> > > > >
> > > > > I've had to put HHH-9091 on hold while I fix HHH-8401, but will
> need to
> > > > > get back to it shortly.
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Steve Ebersole" <steve(a)hibernate.org>
> > > > > > To: "Gail Badner" <gbadner(a)redhat.com>
> > > > > > Sent: Wednesday, December 10, 2014 8:45:13 AM
> > > > > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne
> > > > > >
> > > > > > Actually, I would think databases would not treat null values in
> a FK
> > > > > > column as being a constraint violation. Null is not a value.
> Do you
> > > > > have
> > > > > > specific details about that concretely? Databases I have worked
> > > with do
> > > > > > not behave that way.
> > > > > >
> > > > > > On Dec 2, 2014 11:34 PM, "Gail Badner" <gbadner(a)redhat.com>
> wrote:
> > > > > > >
> > > > > > > I'm a bit confused by the mapping defaults for @OneToOne
> defined
> > > in JPA
> > > > > > 2.1.
> > > > > > >
> > > > > > > Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional
> > > OneToOne
> > > > > > Relationships) says, "The foreign key column has the same type
> as the
> > > > > > primary key of table B and there is a unique key constraint on
> it."
> > > > > > >
> > > > > > > Section 11.1.41 (OneToOne Annotation) says that, by default,
> > > > > > optional=true, which translates into nullable foreign key
> column(s).
> > > > > > >
> > > > > > > IIUC, the default mapping is not supported by many (all?)
> > > databases,
> > > > > > because a constraint violation exception will be thrown if a
> column
> > > has a
> > > > > > unique key constraint and there is more than one null value for
> that
> > > > > column.
> > > > > > >
> > > > > > > Currently, Hibernate does not create a unique key unless
> @OneToOne(
> > > > > > optional=false ) is defined. I believe Hibernate is doing the
> right
> > > thing
> > > > > > here, but it is not consistent with the spec.
> > > > > > >
> > > > > > > Is the spec wrong in this case, or am I missing something?
> Please
> > > let
> > > > > me
> > > > > > know...
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Gail
> > > > > > > _______________________________________________
> > > > > > > hibernate-dev mailing list
> > > > > > > hibernate-dev(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > > >
> > > > >
> > > >
> > >
> >
>
10 years, 10 months
Re: [hibernate-dev] Mapping defaults for @OneToOne
by Steve Ebersole
Are you asking me what "leveing rules" are? ANSI SQL defines a number of
levels of conformance: entry, intermediate and full. These leveling rules
describe additional rules/restrictions/limitations for certain conformance
level.
Taking a step back... a unique constraint says that the column(s) listed in
the constraint specification must contain unique values. Well how do we
know values are unique? We know because they are not equal to one
another. And how does ANSI SQL define equality wrt NULL? It says that
NULLs are never equal. So how can they violate a unique constraint?
*If* we are to make any change here, I think what might be worthwhile is to
have the Dialect indicate what level of conformance it suports wrt unique
constraints. If the Dialect reports FULL or INTERMEDIATE support, then we
would support building a UK on nullable columns; if it reports ENTRY, we
would not.
On Dec 11, 2014 2:54 PM, "Gail Badner" <gbadner(a)redhat.com> wrote:
> I check several dialects (can't remember exactly which ones)
>
> I see the following in
> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt in 11.7 <unique
> constraint definition>:
>
> Leveling Rules
>
> 1) The following restrictions apply for Intermediate SQL:
>
> None.
>
> 2) The following restrictions apply for Entry SQL in addition to
> any Intermediate SQL restrictions:
>
> a) If PRIMARY KEY or UNIQUE is specified, then the <column
> defi-
> nition> for each column whose <column name> is in the <unique
> column list> shall specify NOT NULL.
>
> To be honest, I don't know how these leveling rules are supposed to work.
> Do you?
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve(a)hibernate.org>
> > To: "Gail Badner" <gbadner(a)redhat.com>
> > Sent: Wednesday, December 10, 2014 5:07:37 PM
> > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne
> >
> > The point is the same. ANSI SQL even states that unique keys should
> > disallow duplicate *non null* values but allow multiple rows with null.
> > Again, it just makes sense; null is *not* a value.
> >
> > Does some database not support that? Yeah ok maybe
> > On Dec 10, 2014 2:46 PM, "Gail Badner" <gbadner(a)redhat.com> wrote:
> >
> > > The problem here is not that the FK has a null value. The problem is
> that
> > > the FK column has a unique constraint. It's the unique constraint that
> > > throws an exception when there is more than one null value for that
> column.
> > >
> > > I chatted with Emmanuel about this topic:
> > >
> > > (01:26:57 PM) emmanuel: gbadner: BTW if that's about your email on -dev
> > > and if for real DBs consider null as a unique value, then I think
> Hibernate
> > > doe sthr right thing by not enforcing
> > > (01:26:59 PM) emmanuel: it
> > >
> > > (01:37:13 PM) gbadner: emmanuel, what does that mean wrt to the spec?
> > > (01:37:37 PM) gbadner: is hibernate non-compliant, but does the right
> > > thing?
> > > (01:37:39 PM) emmanuel: the spec is not the gospel
> > > (01:38:10 PM) gbadner: there is an inconsistency between hbm.xml and
> > > annotations
> > > (01:39:02 PM) gbadner: the reason I care is that I have a fix for an
> issue
> > > that works for annotations, but not hbm.xml
> > > (01:39:34 PM) gbadner: the reason it works for annotations is because
> > > there is no unique constraint when the @OneToOne is optional
> > > (01:41:45 PM) gbadner: what *should* hibernate do when hbm.xml has:
> > > not-null="false" unique="true" ?
> > > (01:42:21 PM) emmanuel: hbm has always philosophically been close to
> the
> > > physicla model
> > > (01:42:22 PM) gbadner: currently, hibernate goes ahead and creates the
> > > unique constraint
> > > (01:42:34 PM) emmanuel: so applying the unique constraint would be
> what I
> > > expect
> > > (01:43:25 PM) gbadner: but should hibernate also override with
> > > not-null="true" when unique="true"?
> > > (01:44:03 PM) gbadner: ^^^ and give a warning?
> > > (01:45:30 PM) emmanuel: gbadner: I don't think I would expect that from
> > > hbm, no
> > > (01:45:49 PM) emmanuel: afterall it might be applicable for some
> database
> > > (01:45:50 PM) emmanuel: s
> > > (01:46:03 PM) emmanuel: (but even if it was not, hbm is explicit as I
> > > mentioned)
> > > (01:46:57 PM) gbadner: hibernate *knows* when a column is
> non-nullable; I
> > > don't think it knows when there is a unique constraint
> > > (01:47:26 PM) gbadner: well, I suppose the best Hibernate can do is
> just
> > > assume there is a unique constraint
> > >
> > > My fix for HHH-9091 (really it's a hack) is not acceptable because it
> will
> > > cause regressions for hbm.xml mappings.
> > >
> > > HHH-9091 is caused by HHH-6484. HHH-6484 made a change to execute
> orphan
> > > deletes before anything else, which causes a regression as illustrated
> in
> > >
> https://github.com/hibernate/hibernate-orm/commit/c068b6f70c84476db7a0cd2...
> > > .
> > >
> > > At the very least, orphan-deletes must be executed in the proper
> order. I
> > > have to think more about whether are other dependencies that need to be
> > > taken into account.
> > >
> > > I've had to put HHH-9091 on hold while I fix HHH-8401, but will need to
> > > get back to it shortly.
> > >
> > > ----- Original Message -----
> > > > From: "Steve Ebersole" <steve(a)hibernate.org>
> > > > To: "Gail Badner" <gbadner(a)redhat.com>
> > > > Sent: Wednesday, December 10, 2014 8:45:13 AM
> > > > Subject: Re: [hibernate-dev] Mapping defaults for @OneToOne
> > > >
> > > > Actually, I would think databases would not treat null values in a FK
> > > > column as being a constraint violation. Null is not a value. Do you
> > > have
> > > > specific details about that concretely? Databases I have worked
> with do
> > > > not behave that way.
> > > >
> > > > On Dec 2, 2014 11:34 PM, "Gail Badner" <gbadner(a)redhat.com> wrote:
> > > > >
> > > > > I'm a bit confused by the mapping defaults for @OneToOne defined
> in JPA
> > > > 2.1.
> > > > >
> > > > > Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional
> OneToOne
> > > > Relationships) says, "The foreign key column has the same type as the
> > > > primary key of table B and there is a unique key constraint on it."
> > > > >
> > > > > Section 11.1.41 (OneToOne Annotation) says that, by default,
> > > > optional=true, which translates into nullable foreign key column(s).
> > > > >
> > > > > IIUC, the default mapping is not supported by many (all?)
> databases,
> > > > because a constraint violation exception will be thrown if a column
> has a
> > > > unique key constraint and there is more than one null value for that
> > > column.
> > > > >
> > > > > Currently, Hibernate does not create a unique key unless @OneToOne(
> > > > optional=false ) is defined. I believe Hibernate is doing the right
> thing
> > > > here, but it is not consistent with the spec.
> > > > >
> > > > > Is the spec wrong in this case, or am I missing something? Please
> let
> > > me
> > > > know...
> > > > >
> > > > > Thanks,
> > > > > Gail
> > > > > _______________________________________________
> > > > > hibernate-dev mailing list
> > > > > hibernate-dev(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > >
> >
>
10 years, 10 months
Redefining the API/SPI/implementation split
by Sanne Grinovero
One of today's issues for Hibernate Search had the goal to move this class:
org.hibernate.search.engine.spi.SearchFactoryImplementor
to not have the "SPI" package postfix as we never meant this to be
part of the SPI but rather an internal contract.
While it's an internal contract, it's functionality is needed by other
modules *in our same repository*, for example hibernate-search-orm
needs to access it.
So we consider it an integration contract across our own shards, but
it's not meant to be used by anyone else.
So it seemed a straight-forward decision to move it to:
org.hibernate.search.engine.impl.SearchFactoryImplementor
However then we need to patch the OSGi descriptor to export this package:
org.hibernate.search.engine.impl
By doing so this will export more than what is strictly necessary - as
there are other classes in there - and this gets Karaf to blow up with
many nasty errors as there are dependent classloaders being triggered
by those other internal components. So we really need to keep those
sealed into the module.
So I was thinking to create a new package classification "internal":
org.hibernate.search.engine.internal.SearchFactoryImplementor
We would export this package via OSGi descriptors, but still the name
should be self-explanatory enough as a warning to other consumers?
Sanne
10 years, 10 months
Re: [hibernate-dev] Closed pull requests
by Steve Ebersole
Well telling me/us which PRs got closed would be a good first step :)
Overall, checking that the PR still applies is a good idea too.
On Thu, Oct 30, 2014 at 5:34 PM, Andrej Golovnin <golovnin(a)gmx.net> wrote:
>
> > On 30.10.2014, at 23:15, Steve Ebersole <steve(a)hibernate.org> wrote:
> >
> > Well maybe rather than being hurt and sensitive maybe just understand
> that it was not intentional. GitHub automatically closed them. It was
> simply a mistake.
> >
> > Or be sensitive and threatening about it. Whichever you think helps you
> best ;)
>
> This does not answer my 1. question. :-) What is the best way to proceed?
> Are you going to reopen the pull requests or should we create new requests?
>
> I think, that at least one of my patches must be modified to be applied to
> the "new master".
>
> Any clear small guide, what we (contributors) should do to reopen the pull
> requests
> or a small info that you will care about the closed pull requests
> and we should sit down, relax and wait until you are done, would be really
> helpful.
>
> >
> > On Oct 30, 2014 11:05 PM, "Andrej Golovnin" <golovnin(a)gmx.net> wrote:
> > Hello Steve,
> >
> > you have closed my pull requests and
> > pull requests from others too without any comment.
> >
> > Should we create a new pull requests for the "new master" branch?
> > Or should we just forget all the time and the work we have invested
> > to create those pull requests and stop submitting any new pull requests
> > in the future?
> >
> > Best regards,
> > Andrej Golovnin
>
>
10 years, 10 months
