Re: [hibernate-dev] Removal of Hibernate Commons Annotations from Hibernate Search -> middle-ground solution?
I don't have a completely satisfying answer to this question, but an ad-hoc solution which may work well enough. The idea is to use SigTest [1] to create a file which contains all the signatures of your public API; This file contains information about method parameter and return types but also inheritance relationships so you find out whether any of your API types extends a type from Hibernate Commons Annotations. This signature file does not contain information about non-exposed references (if private methods or if an API method references a type from HCA via a local variable which should be allowed for your purposes). You also can exclude internal packages from the file altogether. Any reference to types from HCA in that signature file are then a place where you leak HCA through to users. As an experiment, I ran the tool on the engine module and found the following references to HCA types from what I think are members of your public API/SPI: * org.hibernate.search.cfg.spi.SearchConfiguration#getReflectionManager() * org.hibernate.search.engine.spi.AbstractDocumentBuilder# * org.hibernate.search.engine.spi.AbstractDocumentBuilder#getBeanXClass() * org.hibernate.search.engine.spi.DocumentBuilderContainedEntity# * org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity# * org.hibernate.search.engine.spi.DocumentBuilderContainedEntity#getIdGetter() * org.hibernate.search.exception.AssertionFailure extends org.hibernate.annotations.common.AssertionFailure I ran the tool like this: export CLASSPATH=... # e.g. via mvn dependency:build-classpath -pl engine -DincludeScope=compile java -jar ~/tools/sigtest-3.0/lib/sigtestdev.jar Setup -classpath $JAVA_HOME/jre/lib/rt.jar:engine/target/hibernate-search-engine-5.0.0-SNAPSHOT.jar:/$CLASSPATH -static -package org.hibernate.search -exclude org.hibernate.search.query.dsl.impl -exclude org.hibernate.search.engine.metadata.impl -exclude org.hibernate.search.impl -exclude org.hibernate.search.util.logging.impl -exclude org.hibernate.search.util.impl -exclude org.hibernate.search.indexes.impl -exclude org.hibernate.search.bridge.impl -exclude org.hibernate.search.engine.impl -NonClosedFile -FileName search-deps.sig package/exclude specify the API types of interest; NonClosedFile causes only members from the specified search package to be included in the created file. You can then grep search-deps.sig for references to HCA types. Hth, --Gunnar [1] https://wiki.openjdk.java.net/display/CodeTools/SigTest 2014-06-23 21:53 GMT+02:00 Sanne Grinovero : > This has been proposed several times, it's time to try converging on a > stable API for Hibernate Search 5, and I have the idea that actual > plans to remove the dependency are not mature. > > I would then propose to re-purpose HSEARCH-1213 to not fully remove > hibernate-commons-annotations but to use it as an implementation > detail only: make sure we hide it from user API, so to allow us to > remove it later when possibly Hibernate ORM will be aligned on these > plans too. > > Any suggestion on how we could verify this is done correctly? > I thought of using checkstyle to consider it a violation to import > HANN classes in the tests, but that's probably not solid enough - and > some tests might need exceptions to the rule. > > 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] [OGM] Id generation strategies
Yes, today we don't.
But is there any reason for not using the value column name? In fact that's
what my pending PR https://github.com/hibernate/hibernate-ogm/pull/337 does
for MongoDB. Right now it even allows to work with different value column
names for the same table (either in the same or in different
documents/records) but I plan to add a check disallowing this for the sake
of portability to stores with a fixed schema.
2014-06-20 13:00 GMT+02:00 Emmanuel Bernard :
>
> On 19 Jun 2014, at 14:54, Gunnar Morling wrote:
>
> valueColumnName is something that I elected no to use because NoSQL we
>>> bind to so far do not have a strong schema. And at at given
>>> segmentColumnValue only correspond a single value. It would come and bite
>>> me if someone for the same segment value had two different value column
>>> names to differentiate two different sequence.
>>
>>
>> Would it really bite you? I think e.g. MongoDB could perfectly handle
>> this case via two different fields for the two sequences in the same
>> document/segment.
>>
>>
>> @TableGenerator(
>> name=“1”,
>> table=“Seq_table”,
>> pkColumnName=“key”,
>> pkColumnValue=“1”,
>> valueColumnName=“value1”
>> )
>> @TableGenerator(
>> name=“2”,
>> table=“Seq_table”,
>> pkColumnName=“key”,
>> pkColumnValue=“1”,
>> valueColumnName=“value2”
>> )
>>
>> The two definitions share the same options except for valueColumnName.
>> The table is roughly as followed
>>
>> TABLE(Seq_table)
>> key|value1 | value2
>> 1| 10 | 24
>>
>> What would be the MongoDB representation in your approach?
>>
>
> It would look like this:
>
> {
> "_id" : 1,
> "value1" : 10,
> "value2" : 24
> }
>
> So you would get the different sequence values from different fields of
> that same document. But I wouldn't recommend to do so due to the potential
> contention on that single record. Thus I'd raise at least a warning during
> bootstrap. As it's not portable to stores with a fixed schema, I'd rather
> not support it at all, though, and raise an error.
>
>
> Exactly. But that’s the thing, AFAIK we do *not* store it that way today
> as we don’t use valueColumnName. So today we store it like this
>
> {
>“_id”: 1,
>“sequence_value”: 10
> }
>
> so 10 and 24 has to both live at the same time in sequence _value.
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Id generation strategies
On 24 Jun 2014, at 11:50, Gunnar Morling wrote:
> Yes, today we don't.
>
> But is there any reason for not using the value column name?
Not more that the ones I outlined in this thread.
> In fact that's what my pending PR
> https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB. Right
> now it even allows to work with different value column names for the same
> table (either in the same or in different documents/records) but I plan to
> add a check disallowing this for the sake of portability to stores with a
> fixed schema.
I don’t follow that one. A fixed schema would be fine here, just with two
columns instead of one, no?
>
>
> 2014-06-20 13:00 GMT+02:00 Emmanuel Bernard :
>
> On 19 Jun 2014, at 14:54, Gunnar Morling wrote:
>
>>> valueColumnName is something that I elected no to use because NoSQL we bind
>>> to so far do not have a strong schema. And at at given segmentColumnValue
>>> only correspond a single value. It would come and bite me if someone for
>>> the same segment value had two different value column names to
>>> differentiate two different sequence.
>>>
>>> Would it really bite you? I think e.g. MongoDB could perfectly handle this
>>> case via two different fields for the two sequences in the same
>>> document/segment.
>>
>> @TableGenerator(
>> name=“1”,
>> table=“Seq_table”,
>> pkColumnName=“key”,
>> pkColumnValue=“1”,
>> valueColumnName=“value1”
>> )
>> @TableGenerator(
>> name=“2”,
>> table=“Seq_table”,
>> pkColumnName=“key”,
>> pkColumnValue=“1”,
>> valueColumnName=“value2”
>> )
>>
>> The two definitions share the same options except for valueColumnName.
>> The table is roughly as followed
>>
>> TABLE(Seq_table)
>> key|value1 | value2
>> 1| 10 | 24
>>
>> What would be the MongoDB representation in your approach?
>>
>> It would look like this:
>>
>> {
>> "_id" : 1,
>> "value1" : 10,
>> "value2" : 24
>> }
>>
>> So you would get the different sequence values from different fields of that
>> same document. But I wouldn't recommend to do so due to the potential
>> contention on that single record. Thus I'd raise at least a warning during
>> bootstrap. As it's not portable to stores with a fixed schema, I'd rather
>> not support it at all, though, and raise an error.
>
> Exactly. But that’s the thing, AFAIK we do *not* store it that way today as
> we don’t use valueColumnName. So today we store it like this
>
> {
>“_id”: 1,
>“sequence_value”: 10
> }
>
> so 10 and 24 has to both live at the same time in sequence _value.
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Id generation strategies
2014-06-24 14:55 GMT+02:00 Emmanuel Bernard :
>
> On 24 Jun 2014, at 11:50, Gunnar Morling wrote:
>
> Yes, today we don't.
>
> But is there any reason for not using the value column name?
>
>
> Not more that the ones I outlined in this thread.
>
> In fact that's what my pending PR
> https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB.
> Right now it even allows to work with different value column names for the
> same table (either in the same or in different documents/records) but I
> plan to add a check disallowing this for the sake of portability to stores
> with a fixed schema.
>
>
> I don’t follow that one. A fixed schema would be fine here, just with two
> columns instead of one, no?
>
Yes, this could work, though I'm not sure when one would actually want to
make use of such an approach. I guess we can leave it out for now and wait
until we actually have store with a fixed schema.
Btw. ORM itself stumbles upon such configuration (the table is generated
with one of the two columns, causing an error when trying to select from
the other one).
>
>
>
> 2014-06-20 13:00 GMT+02:00 Emmanuel Bernard :
>
>>
>> On 19 Jun 2014, at 14:54, Gunnar Morling wrote:
>>
>> valueColumnName is something that I elected no to use because NoSQL we
bind to so far do not have a strong schema. And at at given
segmentColumnValue only correspond a single value. It would come and bite
me if someone for the same segment value had two different value column
names to differentiate two different sequence.
>>>
>>>
>>> Would it really bite you? I think e.g. MongoDB could perfectly handle
>>> this case via two different fields for the two sequences in the same
>>> document/segment.
>>>
>>>
>>> @TableGenerator(
>>> name=“1”,
>>> table=“Seq_table”,
>>> pkColumnName=“key”,
>>> pkColumnValue=“1”,
>>> valueColumnName=“value1”
>>> )
>>> @TableGenerator(
>>> name=“2”,
>>> table=“Seq_table”,
>>> pkColumnName=“key”,
>>> pkColumnValue=“1”,
>>> valueColumnName=“value2”
>>> )
>>>
>>> The two definitions share the same options except for valueColumnName.
>>> The table is roughly as followed
>>>
>>> TABLE(Seq_table)
>>> key|value1 | value2
>>> 1| 10 | 24
>>>
>>> What would be the MongoDB representation in your approach?
>>>
>>
>> It would look like this:
>>
>> {
>> "_id" : 1,
>> "value1" : 10,
>> "value2" : 24
>> }
>>
>> So you would get the different sequence values from different fields of
>> that same document. But I wouldn't recommend to do so due to the potential
>> contention on that single record. Thus I'd raise at least a warning during
>> bootstrap. As it's not portable to stores with a fixed schema, I'd rather
>> not support it at all, though, and raise an error.
>>
>>
>> Exactly. But that’s the thing, AFAIK we do *not* store it that way today
>> as we don’t use valueColumnName. So today we store it like this
>>
>> {
>>“_id”: 1,
>>“sequence_value”: 10
>> }
>>
>> so 10 and 24 has to both live at the same time in sequence _value.
>>
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations
Gunnar and I discussed this on IRC. In my opinion, the easiest solution is to make GridDialect associated with the StandardServiceRegistry, not the SessionFactoryServiceRegistry. Gunnar was going to see if this was possible. This would actually align with how ORM does it where Dialect and JDBC related services are part of the StandardServiceRegistry. What would that gain you? Keep in mind that the IdentifierGeneratorFactory is also a service that is kept in the StandardServiceRegistry. So by making GridDialect part of the same registry, your custom IdentifierGeneratorFactory impl would have access to the GridDialect as it is building its generators ( OgmTableGenerator/OgmSequenceGenerator). On Fri, Jun 20, 2014 at 7:46 AM, Gunnar Morling wrote: > Steve, all, > > I would like to work with a custom IdentifierGeneratorFactory which > performs a specific configuration of created generators (basically I want > to pass OGM's GridDialect instead of the original Dialect contract). > > Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in > Configuration, from where it is accessed in the SessionFactoryImpl > constructor. In my particular case the instantiation of Configuration is > not under my control, so I can't sneak in a custom factory via a sub-class. > Interestingly, (Mutable)IdentifierGeneratorFactory is also a service > contract and as such is accessed via the service registry in other places. > > My understanding is that Configuration is supposed to go away in ORM 5 > anyways, so I'm wondering whether there is a low-effort solution to my > problem as of 4.3.x. > > Would it be feasible to add Configuration#setIdentifierGeneratorFactory() > for that purpose? This should help my case; It would require though that > Configuration#mapping is calculated lazily since atm. it captures a > reference to the initially set generator factory. > > Any thoughts? > > Thanks, > > --Gunnar > ___ > 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] JdbcSession proposal
I pushed a test case that simulates what can happen with remote EJB invocations that share the same JTA transaction & EntityManager. The "Transaction was rolled back in a different thread!" error [2] is thrown but shouldn't be, since the active application thread has changed to a different thread (which can happen). The workaround is to set "hibernate.jta.track_by_thread" to false. I think that we need to save the thread id at the start of every application call into the EntityManager. Scott [1] https://github.com/scottmarlow/hibernate-orm/tree/sametx_multithreads [2] https://gist.github.com/scottmarlow/63c4ab686368853d759b ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations
Gunnar, I think the reason it was a SessionFactoryServiceRegistry is because it depends on the DatastoreProvider which itself needed to be called by our custom OgmSessionFactoryServiceRegistry which calls StartStoppable (DatastoreProviders can also implement StartStoppable. Also, it seems your new GridDialect Initiator uses EventListenerRegistry which is SessionFactoryServiceRegistry specific. If you dodge these two, we can make GridDialect a StandardServiceRegistry citizen. Emmanuel On 24 Jun 2014, at 19:01, Steve Ebersole wrote: > Gunnar and I discussed this on IRC. In my opinion, the easiest solution is > to make GridDialect associated with the StandardServiceRegistry, not the > SessionFactoryServiceRegistry. Gunnar was going to see if this was > possible. This would actually align with how ORM does it where Dialect and > JDBC related services are part of the StandardServiceRegistry. > > What would that gain you? Keep in mind that the IdentifierGeneratorFactory > is also a service that is kept in the StandardServiceRegistry. So by > making GridDialect part of the same registry, your custom > IdentifierGeneratorFactory > impl would have access to the GridDialect as it is building its generators ( > OgmTableGenerator/OgmSequenceGenerator). > > > > On Fri, Jun 20, 2014 at 7:46 AM, Gunnar Morling > wrote: > >> Steve, all, >> >> I would like to work with a custom IdentifierGeneratorFactory which >> performs a specific configuration of created generators (basically I want >> to pass OGM's GridDialect instead of the original Dialect contract). >> >> Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in >> Configuration, from where it is accessed in the SessionFactoryImpl >> constructor. In my particular case the instantiation of Configuration is >> not under my control, so I can't sneak in a custom factory via a sub-class. >> Interestingly, (Mutable)IdentifierGeneratorFactory is also a service >> contract and as such is accessed via the service registry in other places. >> >> My understanding is that Configuration is supposed to go away in ORM 5 >> anyways, so I'm wondering whether there is a low-effort solution to my >> problem as of 4.3.x. >> >> Would it be feasible to add Configuration#setIdentifierGeneratorFactory() >> for that purpose? This should help my case; It would require though that >> Configuration#mapping is calculated lazily since atm. it captures a >> reference to the initially set generator factory. >> >> Any thoughts? >> >> Thanks, >> >> --Gunnar >> ___ >> 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] [OGM] Id generation strategies
On 24 Jun 2014, at 15:07, Gunnar Morling wrote: > 2014-06-24 14:55 GMT+02:00 Emmanuel Bernard : > > On 24 Jun 2014, at 11:50, Gunnar Morling wrote: > >> Yes, today we don't. >> >> But is there any reason for not using the value column name? > > Not more that the ones I outlined in this thread. > >> In fact that's what my pending PR >> https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB. Right >> now it even allows to work with different value column names for the same >> table (either in the same or in different documents/records) but I plan to >> add a check disallowing this for the sake of portability to stores with a >> fixed schema. > > I don’t follow that one. A fixed schema would be fine here, just with two > columns instead of one, no? > > Yes, this could work, though I'm not sure when one would actually want to > make use of such an approach. I guess we can leave it out for now and wait > until we actually have store with a fixed schema. > > Btw. ORM itself stumbles upon such configuration (the table is generated with > one of the two columns, causing an error when trying to select from the other > one). Yes, I suspected so. The generation gets lost in that. But one can write its own DDL script. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
