[hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Nicolas Helleringer]

Hi all,

Sanne and I have been wondering about the way the spatial
branch/module/functionality for Hibernate Search shall store its
coordinates in the Lucene index.

Today it is implemented with decimal degree for :
- easy debugging/readability
- ease of conversion on storage as we want to accept mainly decimal degree
from users data

Sanne pointed out that when the search is done there is quite a few
conversion to radians for distance calculation and suggested that we may
store directly coordinates under their radians form.

I have tried a patch to implement this and as I was coding it I feel that
the code was less readable, in the coordinates normalisation mainly and
that there was as many conversion as before.
Conversions had moved from search to import / export of coordinates in and
out the spatial module scope to user scope.

What the docs does not tell (yet), is that we are waiting for WGS 84 (this
is a coordinate system) decimal degree coordinates input, as these are
quite a de facto standard (GPS output this way).

Today this is not the purpose of Hibernate Search spatial initiative to
handle projections. There are opensource libs to handle that on user side
very well (Proj4j)

So. The question is : shall we store as radians or decimal degree ?

Niko

P.S : Hope it is clear. If not ask for more.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Sanne Grinovero]

The reason for my comment is that the code is doing a conversion to
radians in the DistanceFilter, which needs to be extremely efficient
as it's not only applied on the resultset but potentially on the whole
corpus of all Documents in the index.
So even if it's true that conversion would be needed on the final
results, we always expect people to retrieve only a limited amount of
entities (like with pagination), while the index might need to perform
this computation millions of times per query.

If I look at the complexity of Point.getDistanceTo(double, double), I
get a feeling that that method will hardly provide speedy queries
because of the complex computations in it - this is just speculation
at this point of course, to be sure we'd need to compare them with a
large enough dataset, but it seems quite obvious that storing
normalized radians should be more efficient as it would avoid a good
deal of math to be executed on each Document in the index.

Also if we assume people might want to use radians in their user data
(I know some who definitely would never touch decimals for such a use
case), there would be no need at all to convert the end result.

Some more thoughts inline:

On 3 May 2012 09:12, Nicolas Helleringer  wrote:
> Hi all,
>
> Sanne and I have been wondering about the way the spatial
> branch/module/functionality for Hibernate Search shall store its
> coordinates in the Lucene index.
>
> Today it is implemented with decimal degree for :
> - easy debugging/readability
> - ease of conversion on storage as we want to accept mainly decimal degree
> from users data

Valid points, but consider that "storage" is going to be way slower
anyway, and typically you'll process a Document to evaluate it for a
hit many many orders of magnitude more frequently than the times you
store it.

>
> Sanne pointed out that when the search is done there is quite a few
> conversion to radians for distance calculation and suggested that we may
> store directly coordinates under their radians form.
>
> I have tried a patch to implement this and as I was coding it I feel that
> the code was less readable, in the coordinates normalisation mainly and
> that there was as many conversion as before.
> Conversions had moved from search to import / export of coordinates in and
> out the spatial module scope to user scope.

I'm sure the amount of points in the code in which they are converted
won't change. I'm concerned about the cardinality of the collections
on which it's applied ;)
"Less readable" isn't nice, but we can work on that I guess?

>
> What the docs does not tell (yet), is that we are waiting for WGS 84 (this
> is a coordinate system) decimal degree coordinates input, as these are
> quite a de facto standard (GPS output this way).

How does it affect this?

>
> Today this is not the purpose of Hibernate Search spatial initiative to
> handle projections. There are opensource libs to handle that on user side
> very well (Proj4j)
>
> So. The question is : shall we store as radians or decimal degree ?
>
> Niko
>
> P.S : Hope it is clear. If not ask for more.

Thanks!
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Emmanuel Bernard]

Let me see if I understood by rephrasing. I am trying to get a feel of where 
conversions happen.

I am assuming that this is mostly relevant for the boolean query approach and 
the later circle memory filtering (ie that quad tree is not involved).

Today we accept decimal coordinates from the user and store them as is in the 
index. But to calculate the right rectangle and then circle filter when 
we build a query and later filter elements in memory (circle): 

- we convert the query coordinates into radians to find the right box 
boundaries coordinates and convert them back into decimals
- for each matching element in the box we further convert the coordinates in 
radian to filter by circle

In the new scheme where radians are stored, we would:

- receive coordinates from the user as decimals
- convert them to radians once at indexing time and once at query time

So the big difference would be that we avoid the per element in the box 
filtering conversion from decimals to radians.

Am I correct or completely wrong?

On 3 mai 2012, at 10:12, Nicolas Helleringer wrote:

> Hi all,
> 
> Sanne and I have been wondering about the way the spatial
> branch/module/functionality for Hibernate Search shall store its
> coordinates in the Lucene index.
> 
> Today it is implemented with decimal degree for :
> - easy debugging/readability
> - ease of conversion on storage as we want to accept mainly decimal degree
> from users data
> 
> Sanne pointed out that when the search is done there is quite a few
> conversion to radians for distance calculation and suggested that we may
> store directly coordinates under their radians form.
> 
> I have tried a patch to implement this and as I was coding it I feel that
> the code was less readable, in the coordinates normalisation mainly and
> that there was as many conversion as before.
> Conversions had moved from search to import / export of coordinates in and
> out the spatial module scope to user scope.
> 
> What the docs does not tell (yet), is that we are waiting for WGS 84 (this
> is a coordinate system) decimal degree coordinates input, as these are
> quite a de facto standard (GPS output this way).
> 
> Today this is not the purpose of Hibernate Search spatial initiative to
> handle projections. There are opensource libs to handle that on user side
> very well (Proj4j)
> 
> So. The question is : shall we store as radians or decimal degree ?
> 
> Niko
> 
> P.S : Hope it is clear. If not ask for more.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Emmanuel Bernard]

How comes the DistanceFilter has to compute the distance for the whole corpus?

By the way the actual storage (say via Hibernate ORM, or Infinispan) does not 
need to store in radian, so we don't need to do a conversion when reading an 
entity.

On 3 mai 2012, at 10:45, Sanne Grinovero wrote:

> The reason for my comment is that the code is doing a conversion to
> radians in the DistanceFilter, which needs to be extremely efficient
> as it's not only applied on the resultset but potentially on the whole
> corpus of all Documents in the index.
> So even if it's true that conversion would be needed on the final
> results, we always expect people to retrieve only a limited amount of
> entities (like with pagination), while the index might need to perform
> this computation millions of times per query.
> 
> If I look at the complexity of Point.getDistanceTo(double, double), I
> get a feeling that that method will hardly provide speedy queries
> because of the complex computations in it - this is just speculation
> at this point of course, to be sure we'd need to compare them with a
> large enough dataset, but it seems quite obvious that storing
> normalized radians should be more efficient as it would avoid a good
> deal of math to be executed on each Document in the index.
> 
> Also if we assume people might want to use radians in their user data
> (I know some who definitely would never touch decimals for such a use
> case), there would be no need at all to convert the end result.
> 
> Some more thoughts inline:
> 
> On 3 May 2012 09:12, Nicolas Helleringer  
> wrote:
>> Hi all,
>> 
>> Sanne and I have been wondering about the way the spatial
>> branch/module/functionality for Hibernate Search shall store its
>> coordinates in the Lucene index.
>> 
>> Today it is implemented with decimal degree for :
>> - easy debugging/readability
>> - ease of conversion on storage as we want to accept mainly decimal degree
>> from users data
> 
> Valid points, but consider that "storage" is going to be way slower
> anyway, and typically you'll process a Document to evaluate it for a
> hit many many orders of magnitude more frequently than the times you
> store it.
> 
>> 
>> Sanne pointed out that when the search is done there is quite a few
>> conversion to radians for distance calculation and suggested that we may
>> store directly coordinates under their radians form.
>> 
>> I have tried a patch to implement this and as I was coding it I feel that
>> the code was less readable, in the coordinates normalisation mainly and
>> that there was as many conversion as before.
>> Conversions had moved from search to import / export of coordinates in and
>> out the spatial module scope to user scope.
> 
> I'm sure the amount of points in the code in which they are converted
> won't change. I'm concerned about the cardinality of the collections
> on which it's applied ;)
> "Less readable" isn't nice, but we can work on that I guess?
> 
>> 
>> What the docs does not tell (yet), is that we are waiting for WGS 84 (this
>> is a coordinate system) decimal degree coordinates input, as these are
>> quite a de facto standard (GPS output this way).
> 
> How does it affect this?
> 
>> 
>> Today this is not the purpose of Hibernate Search spatial initiative to
>> handle projections. There are opensource libs to handle that on user side
>> very well (Proj4j)
>> 
>> So. The question is : shall we store as radians or decimal degree ?
>> 
>> Niko
>> 
>> P.S : Hope it is clear. If not ask for more.
> 
> Thanks!
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Nicolas Helleringer]

2012/5/3 Sanne Grinovero 

> The reason for my comment is that the code is doing a conversion to
> radians in the DistanceFilter, which needs to be extremely efficient
> as it's not only applied on the resultset but potentially on the whole
> corpus of all Documents in the index.
> So even if it's true that conversion would be needed on the final
> results, we always expect people to retrieve only a limited amount of
> entities (like with pagination), while the index might need to perform
> this computation millions of times per query.
>
You re right.


> If I look at the complexity of Point.getDistanceTo(double, double), I
> get a feeling that that method will hardly provide speedy queries
> because of the complex computations in it - this is just speculation
> at this point of course, to be sure we'd need to compare them with a
> large enough dataset, but it seems quite obvious that storing
> normalized radians should be more efficient as it would avoid a good
> deal of math to be executed on each Document in the index.
>
Radians storage saves 5 double multiplication in a method with 2 sinus, 2
power, 2 cosinus, 2 sqrt and 1 atan2.
IMO it hardly makes a mark but yes I do agree it is a gain.


> Also if we assume people might want to use radians in their user data
> (I know some who definitely would never touch decimals for such a use
> case), there would be no need at all to convert the end result.
>
Right


>
> Some more thoughts inline:
>
> On 3 May 2012 09:12, Nicolas Helleringer 
> wrote:
> > Hi all,
> >
> > Sanne and I have been wondering about the way the spatial
> > branch/module/functionality for Hibernate Search shall store its
> > coordinates in the Lucene index.
> >
> > Today it is implemented with decimal degree for :
> > - easy debugging/readability
> > - ease of conversion on storage as we want to accept mainly decimal
> degree
> > from users data
>
> Valid points, but consider that "storage" is going to be way slower
> anyway, and typically you'll process a Document to evaluate it for a
> hit many many orders of magnitude more frequently than the times you
> store it.

RIght


> >
> > Sanne pointed out that when the search is done there is quite a few
> > conversion to radians for distance calculation and suggested that we may
> > store directly coordinates under their radians form.
> >
> > I have tried a patch to implement this and as I was coding it I feel that
> > the code was less readable, in the coordinates normalisation mainly and
> > that there was as many conversion as before.
> > Conversions had moved from search to import / export of coordinates in
> and
> > out the spatial module scope to user scope.
>
> I'm sure the amount of points in the code in which they are converted
> won't change. I'm concerned about the cardinality of the collections
> on which it's applied ;)
> "Less readable" isn't nice, but we can work on that I guess?
>
Right


>
> >
> > What the docs does not tell (yet), is that we are waiting for WGS 84
> (this
> > is a coordinate system) decimal degree coordinates input, as these are
> > quite a de facto standard (GPS output this way).
>
> How does it affect this?
>
Not at all. Should have been noted in my todo list. not in tha mail =)


>
> >
> > Today this is not the purpose of Hibernate Search spatial initiative to
> > handle projections. There are opensource libs to handle that on user side
> > very well (Proj4j)
> >
> > So. The question is : shall we store as radians or decimal degree ?
> >
> > Niko
> >
> > P.S : Hope it is clear. If not ask for more.
>
> Thanks!
> Sanne
>

I ll do a full patch ASAP.

Niko
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Nicolas Helleringer]

2012/5/3 Emmanuel Bernard 

> Let me see if I understood by rephrasing. I am trying to get a feel of
> where conversions happen.
>
> I am assuming that this is mostly relevant for the boolean query approach
> and the later circle memory filtering (ie that quad tree is not involved).
>
In Quad Tree mode you still have to filter by distance the candidates
returned by the Quad Tree. This still applies.


> Today we accept decimal coordinates from the user and store them as is in
> the index. But to calculate the right rectangle and then circle filter when
> we build a query and later filter elements in memory (circle):



>

- we convert the query coordinates into radians to find the right box
> boundaries coordinates and convert them back into decimals
>
no : the box used in simple mode is calculated in decimal degrees

> - for each matching element in the box we further convert the coordinates
> in radian to filter by circle
>
yes


> In the new scheme where radians are stored, we would:
>
> - receive coordinates from the user as decimals
> - convert them to radians once at indexing time and once at query time
>
yes


> So the big difference would be that we avoid the per element in the box
> filtering conversion from decimals to radians.
>
no : the diffrerence is only durring the distance filtering as Sanne said


> Am I correct or completely wrong?

not completly =)

Niko


>  On 3 mai 2012, at 10:12, Nicolas Helleringer wrote:
>
> > Hi all,
> >
> > Sanne and I have been wondering about the way the spatial
> > branch/module/functionality for Hibernate Search shall store its
> > coordinates in the Lucene index.
> >
> > Today it is implemented with decimal degree for :
> > - easy debugging/readability
> > - ease of conversion on storage as we want to accept mainly decimal
> degree
> > from users data
> >
> > Sanne pointed out that when the search is done there is quite a few
> > conversion to radians for distance calculation and suggested that we may
> > store directly coordinates under their radians form.
> >
> > I have tried a patch to implement this and as I was coding it I feel that
> > the code was less readable, in the coordinates normalisation mainly and
> > that there was as many conversion as before.
> > Conversions had moved from search to import / export of coordinates in
> and
> > out the spatial module scope to user scope.
> >
> > What the docs does not tell (yet), is that we are waiting for WGS 84
> (this
> > is a coordinate system) decimal degree coordinates input, as these are
> > quite a de facto standard (GPS output this way).
> >
> > Today this is not the purpose of Hibernate Search spatial initiative to
> > handle projections. There are opensource libs to handle that on user side
> > very well (Proj4j)
> >
> > So. The question is : shall we store as radians or decimal degree ?
> >
> > Niko
> >
> > P.S : Hope it is clear. If not ask for more.
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Sanne Grinovero]

Correct.

On 3 May 2012 10:07, Emmanuel Bernard  wrote:
> Let me see if I understood by rephrasing. I am trying to get a feel of where 
> conversions happen.
>
> I am assuming that this is mostly relevant for the boolean query approach and 
> the later circle memory filtering (ie that quad tree is not involved).
>
> Today we accept decimal coordinates from the user and store them as is in the 
> index. But to calculate the right rectangle and then circle filter when
> we build a query and later filter elements in memory (circle):
>
> - we convert the query coordinates into radians to find the right box 
> boundaries coordinates and convert them back into decimals
> - for each matching element in the box we further convert the coordinates in 
> radian to filter by circle
>
> In the new scheme where radians are stored, we would:
>
> - receive coordinates from the user as decimals
> - convert them to radians once at indexing time and once at query time
>
> So the big difference would be that we avoid the per element in the box 
> filtering conversion from decimals to radians.
>
> Am I correct or completely wrong?
>
> On 3 mai 2012, at 10:12, Nicolas Helleringer wrote:
>
>> Hi all,
>>
>> Sanne and I have been wondering about the way the spatial
>> branch/module/functionality for Hibernate Search shall store its
>> coordinates in the Lucene index.
>>
>> Today it is implemented with decimal degree for :
>> - easy debugging/readability
>> - ease of conversion on storage as we want to accept mainly decimal degree
>> from users data
>>
>> Sanne pointed out that when the search is done there is quite a few
>> conversion to radians for distance calculation and suggested that we may
>> store directly coordinates under their radians form.
>>
>> I have tried a patch to implement this and as I was coding it I feel that
>> the code was less readable, in the coordinates normalisation mainly and
>> that there was as many conversion as before.
>> Conversions had moved from search to import / export of coordinates in and
>> out the spatial module scope to user scope.
>>
>> What the docs does not tell (yet), is that we are waiting for WGS 84 (this
>> is a coordinate system) decimal degree coordinates input, as these are
>> quite a de facto standard (GPS output this way).
>>
>> Today this is not the purpose of Hibernate Search spatial initiative to
>> handle projections. There are opensource libs to handle that on user side
>> very well (Proj4j)
>>
>> So. The question is : shall we store as radians or decimal degree ?
>>
>> Niko
>>
>> P.S : Hope it is clear. If not ask for more.
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Coordinates storage in Lucene index for spatial functionality

[Sanne Grinovero]

On May 3, 2012 10:10 AM, "Emmanuel Bernard"  wrote:
>
> How comes the DistanceFilter has to compute the distance for the whole
corpus?

You're right in that's not always the case, but it's possible. If there are
more filters enabled and they are executed first, our filter will need to
do the math only on the matched documents by the previous filters, but if
there are no other constraints or filters our DistanceFilter might need to
process all documents in all segments. This happens also when a limit is
enabled on the collector - although limited to the current index segment -
when the filter needs to be cached as it needs to evaluate each document in
the segment.

In our case this DistanceFilter is only applied after RangeQuery was
applied on both longitude and latitude, so I'm not sure if this is a big
problem; personally I was just wondering but I'd be fine in keeping this as
a possible future improvement - but if we go for a separate issue, let's
keep in mind that that the index format would not be backwards compatible.

> By the way the actual storage (say via Hibernate ORM, or Infinispan) does
not need to store in radian, so we don't need to do a conversion when
reading an entity.

Right, another reason to index only in whatever format makes querying more
efficient.

-- Sanne


>
> On 3 mai 2012, at 10:45, Sanne Grinovero wrote:
>
> > The reason for my comment is that the code is doing a conversion to
> > radians in the DistanceFilter, which needs to be extremely efficient
> > as it's not only applied on the resultset but potentially on the whole
> > corpus of all Documents in the index.
> > So even if it's true that conversion would be needed on the final
> > results, we always expect people to retrieve only a limited amount of
> > entities (like with pagination), while the index might need to perform
> > this computation millions of times per query.
> >
> > If I look at the complexity of Point.getDistanceTo(double, double), I
> > get a feeling that that method will hardly provide speedy queries
> > because of the complex computations in it - this is just speculation
> > at this point of course, to be sure we'd need to compare them with a
> > large enough dataset, but it seems quite obvious that storing
> > normalized radians should be more efficient as it would avoid a good
> > deal of math to be executed on each Document in the index.
> >
> > Also if we assume people might want to use radians in their user data
> > (I know some who definitely would never touch decimals for such a use
> > case), there would be no need at all to convert the end result.
> >
> > Some more thoughts inline:
> >
> > On 3 May 2012 09:12, Nicolas Helleringer 
wrote:
> >> Hi all,
> >>
> >> Sanne and I have been wondering about the way the spatial
> >> branch/module/functionality for Hibernate Search shall store its
> >> coordinates in the Lucene index.
> >>
> >> Today it is implemented with decimal degree for :
> >> - easy debugging/readability
> >> - ease of conversion on storage as we want to accept mainly decimal
degree
> >> from users data
> >
> > Valid points, but consider that "storage" is going to be way slower
> > anyway, and typically you'll process a Document to evaluate it for a
> > hit many many orders of magnitude more frequently than the times you
> > store it.
> >
> >>
> >> Sanne pointed out that when the search is done there is quite a few
> >> conversion to radians for distance calculation and suggested that we
may
> >> store directly coordinates under their radians form.
> >>
> >> I have tried a patch to implement this and as I was coding it I feel
that
> >> the code was less readable, in the coordinates normalisation mainly and
> >> that there was as many conversion as before.
> >> Conversions had moved from search to import / export of coordinates in
and
> >> out the spatial module scope to user scope.
> >
> > I'm sure the amount of points in the code in which they are converted
> > won't change. I'm concerned about the cardinality of the collections
> > on which it's applied ;)
> > "Less readable" isn't nice, but we can work on that I guess?
> >
> >>
> >> What the docs does not tell (yet), is that we are waiting for WGS 84
(this
> >> is a coordinate system) decimal degree coordinates input, as these are
> >> quite a de facto standard (GPS output this way).
> >
> > How does it affect this?
> >
> >>
> >> Today this is not the purpose of Hibernate Search spatial initiative to
> >> handle projections. There are opensource libs to handle that on user
side
> >> very well (Proj4j)
> >>
> >> So. The question is : shall we store as radians or decimal degree ?
> >>
> >> Niko
> >>
> >> P.S : Hope it is clear. If not ask for more.
> >
> > Thanks!
> > Sanne
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-d

[hibernate-dev] Where are the batched fetch statements generated?

[Clemens Eisserer]

Hi,

Sorry for posting to the developers list, I have tried all other
places dedicated to end-user support, however it seems the question is
too in-depth :/

Is it possible to disable prepared statement caching for batched
fetching, so I end up with a single query in the <
default_batch_fetch_size case only instead of the fixed-size batch
loading hibernate does by default?
If its not configureable, I would be really grateful for a pointer to
the source where that caching and sub-batch-by-sub-batch loading is
done.

I am latency bound with a low-loaded postgresql-server, so I would be
happy if I could trade lower server load with less roundtrips.

Thank you in advance, Clemens
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Are you support specification?

[Dmitry Geraskov]

Hi, guys,

I noticed that hibernate excludes unlisted classes even if 
** is set to *false*.
Here is the text from persistence-2_0-final-spec.pdf:

/8.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes
The following classes must be implicitly or explicitly denoted as 
managed persistence classes to be
included within a persistence unit: entity classes; embeddable classes; 
mapped superclasses.
The set of managed persistence classes that are managed by a persistence 
unit is defined by using one or
more of the following:
[81]
. Annotated managed persistence classes contained in the root of the 
persistence unit (*unless the
exclude-unlisted-classes element is specified*) /


/8.2.1.6.1 Annotated Classes in the Root of the Persistence Unit
All classes contained in the root of the persistence unit are searched 
for annotated managed persistence
classes---classes with the
Entity,
Embeddable, or
MappedSuperclass annotation---and any
mapping metadata annotations found on these classes will be processed, 
or they will be mapped using
the mapping annotation defaults. If it is not intended that the 
annotated persistence classes contained in
the root of the persistence unit be included in the persistence unit, the
*exclude-unlisted-classes element must be specified as **true*. The
exclude-unlisted-classes element is not intended for use in Java SE 
environments./

Does this mean you don't support specification in this place?

Here is a link to our jira issue https://issues.jboss.org/browse/JBIDE-11773

Dmitry
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Are you support specification?

[Emmanuel Bernard]

It's expected that people that exclude use



and people that do not want to exclude simply don't add this element.

It's possible that our parsing does not account for people that use the 
explicit form to not exclude. Open a JIRA issue please.

On 3 mai 2012, at 14:12, Dmitry Geraskov wrote:

> Hi, guys,
> 
> I noticed that hibernate excludes unlisted classes even if 
> ** is set to *false*.
> Here is the text from persistence-2_0-final-spec.pdf:
> 
> /8.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes
> The following classes must be implicitly or explicitly denoted as 
> managed persistence classes to be
> included within a persistence unit: entity classes; embeddable classes; 
> mapped superclasses.
> The set of managed persistence classes that are managed by a persistence 
> unit is defined by using one or
> more of the following:
> [81]
> . Annotated managed persistence classes contained in the root of the 
> persistence unit (*unless the
> exclude-unlisted-classes element is specified*) /
> 
> 
> /8.2.1.6.1 Annotated Classes in the Root of the Persistence Unit
> All classes contained in the root of the persistence unit are searched 
> for annotated managed persistence
> classes---classes with the
> Entity,
> Embeddable, or
> MappedSuperclass annotation---and any
> mapping metadata annotations found on these classes will be processed, 
> or they will be mapped using
> the mapping annotation defaults. If it is not intended that the 
> annotated persistence classes contained in
> the root of the persistence unit be included in the persistence unit, the
> *exclude-unlisted-classes element must be specified as **true*. The
> exclude-unlisted-classes element is not intended for use in Java SE 
> environments./
> 
> Does this mean you don't support specification in this place?
> 
> Here is a link to our jira issue https://issues.jboss.org/browse/JBIDE-11773
> 
> Dmitry
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Are you support specification?

[Emmanuel Bernard]

it's actually probable because JAXB - which is what we use I think - is such a 
pain in the neck for these kind of situations.

On 3 mai 2012, at 14:38, Emmanuel Bernard wrote:

> It's expected that people that exclude use
> 
>
> 
> and people that do not want to exclude simply don't add this element.
> 
> It's possible that our parsing does not account for people that use the 
> explicit form to not exclude. Open a JIRA issue please.
> 
> On 3 mai 2012, at 14:12, Dmitry Geraskov wrote:
> 
>> Hi, guys,
>> 
>> I noticed that hibernate excludes unlisted classes even if 
>> ** is set to *false*.
>> Here is the text from persistence-2_0-final-spec.pdf:
>> 
>> /8.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes
>> The following classes must be implicitly or explicitly denoted as 
>> managed persistence classes to be
>> included within a persistence unit: entity classes; embeddable classes; 
>> mapped superclasses.
>> The set of managed persistence classes that are managed by a persistence 
>> unit is defined by using one or
>> more of the following:
>> [81]
>> . Annotated managed persistence classes contained in the root of the 
>> persistence unit (*unless the
>> exclude-unlisted-classes element is specified*) /
>> 
>> 
>> /8.2.1.6.1 Annotated Classes in the Root of the Persistence Unit
>> All classes contained in the root of the persistence unit are searched 
>> for annotated managed persistence
>> classes---classes with the
>> Entity,
>> Embeddable, or
>> MappedSuperclass annotation---and any
>> mapping metadata annotations found on these classes will be processed, 
>> or they will be mapped using
>> the mapping annotation defaults. If it is not intended that the 
>> annotated persistence classes contained in
>> the root of the persistence unit be included in the persistence unit, the
>> *exclude-unlisted-classes element must be specified as **true*. The
>> exclude-unlisted-classes element is not intended for use in Java SE 
>> environments./
>> 
>> Does this mean you don't support specification in this place?
>> 
>> Here is a link to our jira issue https://issues.jboss.org/browse/JBIDE-11773
>> 
>> Dmitry
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Are you support specification?

[Steve Ebersole]

All JAXB stuff is slated for 5.0.  No current code uses JAXB that I am 
aware of.

On Thu 03 May 2012 07:40:08 AM CDT, Emmanuel Bernard wrote:
> it's actually probable because JAXB - which is what we use I think - is such 
> a pain in the neck for these kind of situations.
>
> On 3 mai 2012, at 14:38, Emmanuel Bernard wrote:
>
>> It's expected that people that exclude use
>>
>> 
>>
>> and people that do not want to exclude simply don't add this element.
>>
>> It's possible that our parsing does not account for people that use the 
>> explicit form to not exclude. Open a JIRA issue please.
>>
>> On 3 mai 2012, at 14:12, Dmitry Geraskov wrote:
>>
>>> Hi, guys,
>>>
>>> I noticed that hibernate excludes unlisted classes even if
>>> ** is set to *false*.
>>> Here is the text from persistence-2_0-final-spec.pdf:
>>>
>>> /8.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes
>>> The following classes must be implicitly or explicitly denoted as
>>> managed persistence classes to be
>>> included within a persistence unit: entity classes; embeddable classes;
>>> mapped superclasses.
>>> The set of managed persistence classes that are managed by a persistence
>>> unit is defined by using one or
>>> more of the following:
>>> [81]
>>> . Annotated managed persistence classes contained in the root of the
>>> persistence unit (*unless the
>>> exclude-unlisted-classes element is specified*) /
>>> 
>>>
>>> /8.2.1.6.1 Annotated Classes in the Root of the Persistence Unit
>>> All classes contained in the root of the persistence unit are searched
>>> for annotated managed persistence
>>> classes---classes with the
>>> Entity,
>>> Embeddable, or
>>> MappedSuperclass annotation---and any
>>> mapping metadata annotations found on these classes will be processed,
>>> or they will be mapped using
>>> the mapping annotation defaults. If it is not intended that the
>>> annotated persistence classes contained in
>>> the root of the persistence unit be included in the persistence unit, the
>>> *exclude-unlisted-classes element must be specified as **true*. The
>>> exclude-unlisted-classes element is not intended for use in Java SE
>>> environments./
>>>
>>> Does this mean you don't support specification in this place?
>>>
>>> Here is a link to our jira issue https://issues.jboss.org/browse/JBIDE-11773
>>>
>>> Dmitry
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Are you support specification?

[Dmitry Geraskov]

Done

https://hibernate.onjira.com/browse/HHH-7301


03.05.2012 15:50, Steve Ebersole написал:
> All JAXB stuff is slated for 5.0.  No current code uses JAXB that I am
> aware of.
>
> On Thu 03 May 2012 07:40:08 AM CDT, Emmanuel Bernard wrote:
>> it's actually probable because JAXB - which is what we use I think - is such 
>> a pain in the neck for these kind of situations.
>>
>> On 3 mai 2012, at 14:38, Emmanuel Bernard wrote:
>>
>>> It's expected that people that exclude use
>>>
>>>  
>>>
>>> and people that do not want to exclude simply don't add this element.
>>>
>>> It's possible that our parsing does not account for people that use the 
>>> explicit form to not exclude. Open a JIRA issue please.
>>>
>>> On 3 mai 2012, at 14:12, Dmitry Geraskov wrote:
>>>
 Hi, guys,

 I noticed that hibernate excludes unlisted classes even if
 ** is set to *false*.
 Here is the text from persistence-2_0-final-spec.pdf:

 /8.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes
 The following classes must be implicitly or explicitly denoted as
 managed persistence classes to be
 included within a persistence unit: entity classes; embeddable classes;
 mapped superclasses.
 The set of managed persistence classes that are managed by a persistence
 unit is defined by using one or
 more of the following:
 [81]
 . Annotated managed persistence classes contained in the root of the
 persistence unit (*unless the
 exclude-unlisted-classes element is specified*) /
 

 /8.2.1.6.1 Annotated Classes in the Root of the Persistence Unit
 All classes contained in the root of the persistence unit are searched
 for annotated managed persistence
 classes---classes with the
 Entity,
 Embeddable, or
 MappedSuperclass annotation---and any
 mapping metadata annotations found on these classes will be processed,
 or they will be mapped using
 the mapping annotation defaults. If it is not intended that the
 annotated persistence classes contained in
 the root of the persistence unit be included in the persistence unit, the
 *exclude-unlisted-classes element must be specified as **true*. The
 exclude-unlisted-classes element is not intended for use in Java SE
 environments./

 Does this mean you don't support specification in this place?

 Here is a link to our jira issue 
 https://issues.jboss.org/browse/JBIDE-11773

 Dmitry
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> --
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Are you support specification?

[Emmanuel Bernard]

My bad the code nagivating the data at stake is the W3C DOM API. Not sure why I 
had JAXB in mind.

On 3 mai 2012, at 14:50, Steve Ebersole wrote:

> All JAXB stuff is slated for 5.0.  No current code uses JAXB that I am aware 
> of.
> 
> On Thu 03 May 2012 07:40:08 AM CDT, Emmanuel Bernard wrote:
>> it's actually probable because JAXB - which is what we use I think - is such 
>> a pain in the neck for these kind of situations.
>> 
>> On 3 mai 2012, at 14:38, Emmanuel Bernard wrote:
>> 
>>> It's expected that people that exclude use
>>> 
>>>
>>> 
>>> and people that do not want to exclude simply don't add this element.
>>> 
>>> It's possible that our parsing does not account for people that use the 
>>> explicit form to not exclude. Open a JIRA issue please.
>>> 
>>> On 3 mai 2012, at 14:12, Dmitry Geraskov wrote:
>>> 
 Hi, guys,
 
 I noticed that hibernate excludes unlisted classes even if
 ** is set to *false*.
 Here is the text from persistence-2_0-final-spec.pdf:
 
 /8.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes
 The following classes must be implicitly or explicitly denoted as
 managed persistence classes to be
 included within a persistence unit: entity classes; embeddable classes;
 mapped superclasses.
 The set of managed persistence classes that are managed by a persistence
 unit is defined by using one or
 more of the following:
 [81]
 . Annotated managed persistence classes contained in the root of the
 persistence unit (*unless the
 exclude-unlisted-classes element is specified*) /
 
 
 /8.2.1.6.1 Annotated Classes in the Root of the Persistence Unit
 All classes contained in the root of the persistence unit are searched
 for annotated managed persistence
 classes---classes with the
 Entity,
 Embeddable, or
 MappedSuperclass annotation---and any
 mapping metadata annotations found on these classes will be processed,
 or they will be mapped using
 the mapping annotation defaults. If it is not intended that the
 annotated persistence classes contained in
 the root of the persistence unit be included in the persistence unit, the
 *exclude-unlisted-classes element must be specified as **true*. The
 exclude-unlisted-classes element is not intended for use in Java SE
 environments./
 
 Does this mean you don't support specification in this place?
 
 Here is a link to our jira issue 
 https://issues.jboss.org/browse/JBIDE-11773
 
 Dmitry
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> 
>>> 
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> 
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> --
> st...@hibernate.org
> http://hibernate.org


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Developer IRC meeting - 5/03

[Emmanuel Bernard]

Sorry I could not assist the meeting live but reviewed the logs and had some 
remarks, so ehre are the logs and my remarks :)

## Meeting logs

http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/hibernate-dev.2012-05-03-14.01.html
Minutes 
(text):http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/hibernate-dev.2012-05-03-14.01.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/hibernate-dev.2012-05-03-14.01.log.html

## About parallel arrays vs arrays of objects

Even today, there is a cost in using Objects or HashMap as data placeholders. 
This might not be relevant for us especially since we are not using them for 
"live" data but since memory footprint has always been a concern for Hibernate, 
it's worth mentioning.

This presentation is quite interesting and show the extra memory cost of such 
structure compared to arrays 
http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf

## PessimisticLockException versus LockAcquisitionException

I am not certain of that and Git history got cut short with the migration of 
entitymanager into core. But I do have recollections of some lock exceptions 
that were not catch up and I had to use PessimisticLockException. It could have 
been a change triggered by the TCK. Again I might be wrong, it was a long time 
ago. Plus ORM's core has evolved since.

Emmanuel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Developer IRC meeting - 5/03

[Steve Ebersole]

I seriously doubt the performance cost of 20 'parallel arrays' versus 1 
array of Objects holding those 20 values is anything but negligible at 
best.


On Thu 03 May 2012 11:04:30 AM CDT, Emmanuel Bernard wrote:
> Sorry I could not assist the meeting live but reviewed the logs and had some 
> remarks, so ehre are the logs and my remarks :)
>
> ## Meeting logs
>
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/hibernate-dev.2012-05-03-14.01.html
> Minutes 
> (text):http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/hibernate-dev.2012-05-03-14.01.txt
> Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2012/hibernate-dev.2012-05-03-14.01.log.html
>
> ## About parallel arrays vs arrays of objects
>
> Even today, there is a cost in using Objects or HashMap as data placeholders. 
> This might not be relevant for us especially since we are not using them for 
> "live" data but since memory footprint has always been a concern for 
> Hibernate, it's worth mentioning.
>
> This presentation is quite interesting and show the extra memory cost of such 
> structure compared to arrays 
> http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf
>
> ## PessimisticLockException versus LockAcquisitionException
>
> I am not certain of that and Git history got cut short with the migration of 
> entitymanager into core. But I do have recollections of some lock exceptions 
> that were not catch up and I had to use PessimisticLockException. It could 
> have been a change triggered by the TCK. Again I might be wrong, it was a 
> long time ago. Plus ORM's core has evolved since.
>
> Emmanuel
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Jenkins Jobs

[Steve Ebersole]

Strong, I had to kill hibernate-core-master-matrix job #242.  It had 
been hanging for the last 8+ hours without every even having started any 
of the individual matrix builds.

Is there any way to tell why it has hanging?

-- 
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins Jobs

[Strong Liu]

I think it was just waiting for next available executors, basically there were 
too many jobs in queue waiting to be run

On May 4, 2012, at 3:27 AM, Steve Ebersole wrote:

> Strong, I had to kill hibernate-core-master-matrix job #242.  It had 
> been hanging for the last 8+ hours without every even having started any 
> of the individual matrix builds.
> 
> Is there any way to tell why it has hanging?
> 
> -- 
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins Jobs

[Steve Ebersole]

But I killed it and #243 started *immediately*

On Thu 03 May 2012 02:39:13 PM CDT, Strong Liu wrote:
> I think it was just waiting for next available executors, basically
> there were too many jobs in queue waiting to be run
>
> On May 4, 2012, at 3:27 AM, Steve Ebersole wrote:
>
>> Strong, I had to kill hibernate-core-master-matrix job #242. It had
>> been hanging for the last 8+ hours without every even having started any
>> of the individual matrix builds.
>>
>> Is there any way to tell why it has hanging?
>>
>> --
>> st...@hibernate.org 
>> http://hibernate.org
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> -
> Best Regards,
>
> Strong Liu http://hibernate.org/>>
> http://about.me/stliu/bio
>

--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] long open jiras with patches

[Sanne Grinovero]

Hi All,
I just received notification about the following comment as it seemed
I voted for this issue myself years ago :)

https://hibernate.onjira.com/browse/HHH-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46533#comment-46533

It's sad that we don't have time to apply patches provided by someone
else with best intentions to help, shouldn't we at least reply
something?
Of course that involves myself too, just that I don't feel that
comfortable in evaluating patches for the ORM module.. since this is
long pending I'm assuming someone already looked at it and didn't like
it?

Cheers.
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins Jobs

[Strong Liu]

On May 4, 2012, at 3:45 AM, Steve Ebersole wrote:

> But I killed it and #243 started *immediately*

well, you already know, it sucks

> 
> On Thu 03 May 2012 02:39:13 PM CDT, Strong Liu wrote:
>> I think it was just waiting for next available executors, basically
>> there were too many jobs in queue waiting to be run
>> 
>> On May 4, 2012, at 3:27 AM, Steve Ebersole wrote:
>> 
>>> Strong, I had to kill hibernate-core-master-matrix job #242. It had
>>> been hanging for the last 8+ hours without every even having started any
>>> of the individual matrix builds.
>>> 
>>> Is there any way to tell why it has hanging?
>>> 
>>> --
>>> st...@hibernate.org 
>>> http://hibernate.org
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> -
>> Best Regards,
>> 
>> Strong Liu http://hibernate.org/>>
>> http://about.me/stliu/bio
>> 
> 
> --
> st...@hibernate.org
> http://hibernate.org

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev