After pulling, I am getting a failure executing
:hibernate-core:runAnnotationProcessors.
I tried building with --debug and it looks like the
hibernate-core/target/generated-src/apt/main is deleted without being
re-generated. When hibernate-core is compiled, there are failures because
package o
This is a bit of a potentially insidious one. Not the best way to start
off a discussion, I know :)
The premise is this... Until now Hibernate has represented attribute roles
using dots. For an attribute named 'department' on the com.acme.Employee
entity, the role would be "com.acme.Employee.dep
On 27 Jan 2014, at 19:36, Steve Ebersole wrote:
> Here is what I am trying to decide between in terms of support for this.
> Mainly this is a usability matter for me. Part of usability is how easily we
> can explain this so users can understand and use it. To me there are 2 paths
> to high
On 27 Jan 2014, at 15:17, Steve Ebersole wrote:
> So this is another representation of a choice we are having to make quite a
> bit in 5.0 development... correctness versus "legacy", which has really
> implications for users. So if users are relying on this Hibernate "feature"
> of splitting
Here is what I am trying to decide between in terms of support for this.
Mainly this is a usability matter for me. Part of usability is how easily
we can explain this so users can understand and use it. To me there are 2
paths to high usability here...
== Consistency
The first path would be t
Here is how I phrase this atm in the topical guide:
[NOTE]
It is important to understand that generally speaking the phrase "access
type" refers to a number of concepts:
* Determining which fields/methods constitute a persistent attribute.
* Indicating where to look for mapping annotations.
So this is another representation of a choice we are having to make quite a
bit in 5.0 development... correctness versus "legacy", which has really
implications for users. So if users are relying on this Hibernate
"feature" of splitting identifier mapping annotations between the entity
and the IdC
On Thu, Mar 27, 2014 at 5:36 AM, Hardy Ferentschik wrote:
>
> On 26 Jan 2014, at 22:29, Steve Ebersole wrote:
>
> > BTW, here is the topical guide I have started for this:
> https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/to
This code is 8 years old so no I did not remember.
I did some archeology. The Git migration slots all of that history so I
had to fire up svn.
svn checkout
https://svn.jboss.org/repos/hibernate/annotations/branches/v3_4_0_GA_CP/
svn annotate src/test/java/org/hibernate/test/annotations/cid/OrderL
On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero wrote:
>
> I don't argue with that, but the context of my example was "assuming
> my team has the convention of always putting mappings on properties",
> so in such a case I'd want to use the second.
>
Like I said, I could really live with either in
Hi Hardy,
On Thu, Mar 27, 2014 at 12:52 PM, Hardy Ferentschik wrote:
> I think an example/test would be awesome. Then we have some concrete example
> to base our discussion upon.
I don't think a test would be useful to understand what we do. Here
are a few additional information about our busine
On Thu 2014-03-27 12:40, Hardy Ferentschik wrote:
> > the tricky part is that today SearchFactoryIntegrator extends
> > SearchFactory, but since SearchFactoryIntegrator needs to say in
> > Engine, it can't depend on SearchFactory. What would you think of
> > breaking this parent-child relation?
> >
> My vote goes to #1 as well for the short term.
+1
> we need to share the running containers across
> modules, or merge the integration tests in a single module per
> container.
> Not sure how far Maven will be a problem for this
I think it would be easier to start and download the containers w
On 26 March 2014 20:20, Hardy Ferentschik wrote:
>
> On 26 Jan 2014, at 21:07, Steve Ebersole wrote:
>
>> I also renamed @AccessType (out custom one) to be @AttributeAccessor to
>> better avoid confusion with the JPA names.
>
> +1 Definitely the better choice
I don't argue with that, but the con
On 27 Jan 2014, at 11:35, Guillaume Smet wrote:
> FWIW, we tried to work around it by adding @IndexedEmbedded(depth = 0)
> but as we also have @ContainedIn on transient methods, we can't work
> around it totally.
>
> As usual we are committed to work on a test case and fix once we agree
> it sh
On 27 Jan 2014, at 11:03, Guillaume Smet wrote:
> Before 4.4, when you add a @ContainedIn to a property without the
> corresponding @IndexedEmbedded, they were still added and taken into
> account in the dependency resolution which was quite useful to declare
> dependencies between entities with
On 27 Jan 2014, at 09:17, Guillaume Smet wrote:
> It's really not a big deal if it's compilation errors and we just have
> to reorganize the imports: we clearly see the errors when we upgrade
> so we can fix them easily. You just put it prominently in the release
> notes and it's OK.
My thinkin
On 26 Jan 2014, at 23:11, Sanne Grinovero wrote:
> On 26 March 2014 20:18, Hardy Ferentschik wrote:
>>
>> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote:
>>
>>> The classes in the ORM module are extremely widely used by our primary
>>> target:
>>>
>>> - FullTextQuery
>>> - Search
>>> - Fu
No idea. I think Emmanuel had a better understanding of the derived identifier
logic.
On 27 Jan 2014, at 06:26, Steve Ebersole wrote:
> What's the rational for supporting the following?
>
>
> @Entity
> class Product {
>...
> }
>
> @Entity
> class Order {
>...
> }
>
> @Entity
> @I
On 27 Jan 2014, at 04:29, Steve Ebersole wrote:
> I was looking into some failures on master in regards to XML overrides for
> JPA annotations in relation to our friend Access/AccessType. Which got me
> to thinking...
>
> How does the "mixin" code handle defining the target for the
> Annotatio
On 26 Jan 2014, at 22:29, Steve Ebersole wrote:
> BTW, here is the topical guide I have started for this:
> https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc
Very good start. Missing the m
FWIW, we tried to work around it by adding @IndexedEmbedded(depth = 0)
but as we also have @ContainedIn on transient methods, we can't work
around it totally.
As usual we are committed to work on a test case and fix once we agree
it should be fixed.
On Thu, Mar 27, 2014 at 11:03 AM, Guillaume Sme
On 27 Mar 2014, at 11:18, Emmanuel Bernard wrote:
>
>>
>>> org.hibernate.search.SearchFactory ->
>>> org.hibernate.search.spi.SearchFactory
>>
>> as Emmanuel said, that's an API currently. I'm inclined to think we
>> should convert it to an SPI, and provide a richer more ORM specific
>>
On 26 Mar 2014, at 20:52, Sanne Grinovero wrote:
> Emmanuel, could you elaborate of what you have in mind as "scalability
> reasons”?
Scale as in having more event provider sources (ORM, Infinispan, X, Y, Z). But
we could accept that ORM has historical and privileged rights and will keep the
Hi,
Before 4.4, when you add a @ContainedIn to a property without the
corresponding @IndexedEmbedded, they were still added and taken into
account in the dependency resolution which was quite useful to declare
dependencies between entities without having an explicit
@IndexedEmbedded which are usel
Hi Guillaume,
A Maven plugin for build time enhancement of entities is coded up.
Not without a few problems along the way. But I think we are there now.
Comments are in-lined with your questions.
There should be a plugin in the maven repo soon (if not now) using a
Mojo and the necessary des
Hi,
My 2 cents as an end user of Search: just move them.
It's really not a big deal if it's compilation errors and we just have
to reorganize the imports: we clearly see the errors when we upgrade
so we can fix them easily. You just put it prominently in the release
notes and it's OK.
Most of ou
27 matches
Mail list logo
