Hibernate Development Environment
by Thamayanthi Guhan
Hi Everyone,
I have downloaded the hibernate 3.6 code from git. I had few problem which
i have corrected problem as I am using windows environment. Environment:
Windows Vista, 64bit, Eclipse Galieo. The problem which i faced was gradle
script hibernate-distribution project failing when
${project.basedir} replaced with actual as windows placing path with "\"
than "/". So while running throws exception invalid character. To fix that
problem i modified the file with original path than ${project.basedir}.
Do I to use only Linux environment to work on development activity?
Please help me.
Thanks
Thamayanthi
13 years, 5 months
[HSEARCH] package split in API/SPI/private aka HSEARCH-746
by Emmanuel Bernard
I've started the work to split classes between API, SPI and private classes.
Some areas went very well, some are more problematic but that was to be expected. Anyways it did generate a couple of questions from philosophical to concrete. Please try and chime in.
1.
API vs SPI: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746
I have a question on API vs SPI.
The Hibernate Core team uses the following rule:
- any "public" API not directly called by the user application is a SPI (for example a Bridge would be SPI and I imagine BootStrategy would be too etc).
We could however sue a different rule:
- any API targeted at frameworks integrating with Hibernate Search are SPIs For example SearchConfiguration and SearchFactoryIntegrator would be SPIs but Bridge classes and BoostStrategy would not
I'm tempted by the second definition as it separate user focused classes from integration / framework focused classes. Of course nothing is in back and white and some classes can be hard to categorize.
An aternative approach is to mix the two definitions:
- any "public" API not directly called by the user application is a SPI (for example a Bridge would be SPI and I imagine BootStrategy would be too etc).
- any API targeted at frameworks integrating with Hibernate Search are SPIs For example SearchConfiguration and SearchFactoryIntegrator would be SPIs
But then we lose the distinction between framework APIs and user APIs.
What do you think?
2. Specific issues:
o org.hibernate.search.batchindexing.impl.Executors is used by MutablefactoryTest
should we keep executors as private or should we consider it an actual API or SPI?
o Should built-in types be public APIs/SPIs?
I was tempted to put some if not all as private classes but there are use cases where these classes are used by actual users:
- the programmatic API (ProgrammaticSearchMappingFactory uses them)
- provided id settings
Should we consider some / all as public classes? For example what about ClassBridge?
o Is NumericFieldUtils a public class? It is used by NumericFieldTest, ProjectionQueryTest but it seems a user should not use this helper class
o SearchConfiguration is very likely an SPI which means we will need to break Infinispan's query module, is that OK?
o Programmatic API
*Mapping objects are messed up with *Descriptor objects
It seems to be that *Descriptors should be private while *Mapping should be API, do you think it's worth working on this? The programmatic mapping si still considered experimental so we have some time I guess.
o SearchFactoryIntegrator vs SearchFactoryImplementor
In my mind, I introduced SearchFactoryIntegrator to separate private SearchFactory usage from frameworks usage.
Does the Infinispan Query module depends on SearchFactoryImplementor only? Or is it depending on SearchFactoryImplementor?
That's all for now but more will come :)
Emmanuel
13 years, 6 months
[HSEARCH] Hibernate search core module proposal
by Davide D'Alto
Hi,
today I've downloaded the hibernate-search sources and my eclipse has
a problem importing the maven projects because the parent folder has
the same name as one of the sub-folders:
hibernate-search
|-- hibernate-search
|-- ...
I was a bit surprised because others Hibernate and JBoss projects I
saw so far seem to use the "-core" suffix for the main module.
Shouldn't hibernate-search follow the same convention?
This looks like a good time to review module names for Hibernate Search 4.0
Best regards,
Davide D'Alto
13 years, 6 months
Hibernate OGM
by Alex Snaps
Hey,
I've taken some time and, in an attempt to port Hibernate OGM to use Ehcache instead of Infinispan, abstracted it from Infinispan.
As the doc on that task states, I've made all calls use ConcurrentMap (rather than Map actually). I had a little trouble understanding the "Skip locking proposed by Sanne" in OgmTableGenerator.doWorkInCurrentTransactionIfAny, so that this does a simple Map.get now (that might have been a specialization for a Dialect, but couldn't understand what it was all about).
And finally introduced a new hibernate.grid.manager prop to instantiate the proper provider...
The changes are available here:
https://github.com/alexsnaps/hibernate-ogm/commit/d0fcbffed4c4bcc2aa5208c...
Hope that can be made useful… I also wanted to start looking into queries next. But I'll send another mail on that later.
Thanks,
Alex
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
13 years, 6 months
published groupIds
by Steve Ebersole
As we discussed in a meeting I think 2 weeks ago, I went ahead and spoke
with Paul about renaming the groupIds we use for publishing. He said he
thought it was fine. He did not foresee any issue with doing that.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 6 months
rules of default access
by Strong Liu
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6246
by working on mocking orm xml into jpa annotations, i found the most complicated logic is how to determine access (where mocked annotations, i.e. @Column, go, on property or on field) for an attribute.
by reading jpa spec, i'd think here are the rules of finding default access type for attributes: (correct me if i'm wrong, thanks)
A. get it from attribute directly
1. if the attribute xml element in orm xml has an access property
2. if the attribute has a @Access on its field ( @Access(FIELD) ) or property( @Access(PROPERTY) )
B. get it from Entity (MappedSuperClass, Embeddable)
1. if <entity> has "access"
2. if entity class has @Access
loop: 1,2 with entity's parent
3. if <access> is defined in <persistence-unit-metadata>
C. get it from id attribute
1. if <id> is defined in orm xml and has access attribute
2. if id attribute in entity class has @Id with @Access
3. get the @Id position
loop: 1,2,3 with entity's parent class
D. access= PROPERTY
but wrt default access which defined in <persistence-unit-metadata>, the JPA spec says
{quote}
The access subelement is overridden by the use of any annotations specifying mapping information on the fields or properties of the entity class; by any Access annotation on the entity class, mapped superclass, or embeddable class; by any access subelement of the entity-mappings element; by any Access annotation on a field or property of an entity class, mapped superclass, or embeddable class; by any access attribute defined within an entity, mapped-superclass, or embeddable XML element, or by any access attribute defined within an id, embedded-id, version, basic, embedded, many-to-one, one-to-one, one-to-many, many-to-many, or element-collection element.
{quote}
which "The access subelement is overridden by the use of any annotations specifying mapping information on the fields or properties of the entity class" really confuses Hardy and me.
from our "old" binding code, if defauls access is FIELD, and an entity does not have any @Access nor access in orm, hibernate just ignore all annotations on PROPERTY.
it seems confilcts with above statement from spec...
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
13 years, 7 months
Re: [hibernate-dev] [HSEARCH] Hibernate search core module proposal
by Hardy Ferentschik
On Mon, 23 May 2011 16:58:12 +0200, Sanne Grinovero
<sanne.grinovero(a)gmail.com> wrote:
> It would be fine for me to rename it, assuming it doesn't create a
> mess when backporting patches?
Given our experience w/ Core I would in this case do the rename also on
the 3.6 branch.
At least directory wise. We can always configure the final artifact name
in the pom.
--Hardy
13 years, 7 months
