Re: [hibernate-dev] [Parser] Prefixes used for log messages

[Davide D';Alto]

> My vote goes to #2 as long as we use a shorter code. HQL-1 doesn't
looks too bad.
> In case we incorporate this in ORM I'd change them to HHH- but we can
discuss that if/when that happens.

+1

HQLP as a code perhaps.


On Tue, Aug 27, 2013 at 12:20 PM, Sanne Grinovero wrote:

> My vote goes to #2 as long as we use a shorter code. HQL-1 doesn't
> looks too bad.
>
> In case we incorporate this in ORM I'd change them to HHH- but we can
> discuss that if/when that happens.
>
> On 27 August 2013 10:33, Gunnar Morling  wrote:
> > Hi all,
> >
> > Emmanuel and I are wondering which prefix should be used for log messages
> > created by the parser component ("project code" in JBoss logging
> > nomenclature).
> >
> > I can see the following possibilities:
> >
> > 1) Use HHH-... as in ORM, using a reserved interval of ids
> > 2) Use a new prefix such as HQLPARSER in all messages of all parser
> > components (currently hqlparser-core and hqlparser-lucene), using a
> > reserved id interval for each such component
> > 3) Use a specific prefix for each parser component, e.g. HQLPARSER,
> HQLLUCN
> > etc.
> >
> > I think 3) is the simplest from a dev perspective (no ranges to
> consider),
> > but it may cause a proliferation of prefixes, possibly confusing users.
> 1)
> > may be irritating when using the parser in alternative contexts such as
> > ISPN. As an indicator, I feel it makes sense to use different prefixes
> for
> > code bases living in different repos and with independent release cycle
> (as
> > is the case with ORM and the parser). So I'd vote for 2.
> >
> > Any thoughts?
> >
> > --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

[hibernate-dev] [OGM] Staxmapper dependency in OGM distribution

[Davide D';Alto]

Hi,
I've noticed that the staxmapper-1.1.0.Final.jar is included in the
distribution package in this folders:
infinispan, ehcache, required, mongodb

I checked and it is seems a dependency of infinispan (and arquillian
actually) but I don't understand how come is included in all the folders.

Am I missing something?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [hibernate-announce] OGM 4.0.0.Beta3 released

[Davide D';Alto]

http://in.relation.to/Bloggers/HibernateOGM4Beta3IsOut

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

Re: [hibernate-dev] [OGM] Hibernate OGM @ Devoxx

[Davide D';Alto]

Sounds like a good idea.

Let me know when you have a date.

By the way, congratulations for the event :)

Cheers,
Davide


On Wed, Oct 2, 2013 at 3:15 PM, Emmanuel Bernard wrote:

> Good idea. Plan a hangout and force Davide and Gunnar to be there. I'll
> try and join as well.
> Avoid Oct 14-16th, 22th-23rd and 28th -> Nov 1st
>
> Emmanuel
>
> On Wed 2013-10-02 15:14, Guillaume SCHEIBEL wrote:
> > Thanks, I'm scheduled on Monday at 6:05PM.
> >
> > Hope to see you (all) there :)
> > Guillaume
> >
> > PS: if someone could dedicate ~1h within the month for a dry-run
> session, I
> > would appreciate it.
> >
> > Guillaume
> >
> >
> > 2013/10/2 Emmanuel Bernard 
> >
> > > Nice :)
> > >
> > > On Mon 2013-09-09 15:38, Guillaume SCHEIBEL wrote:
> > > > Hello,
> > > >
> > > > After SoftShake (and few JUGs), I'm proud (and kind of exited) to
> > > announce
> > > > my Tool In Action titled "a hint of NoSQL into my Java EE" has been
> > > > approved.
> > > >
> > > > See you there :)
> > > > Guillaume
> > > > ___
> > > > 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] support for remote grids

[Davide D';Alto]

I can take the HotRod dialect task since I've already some experience with
datastore integration for OGM.
I also don't mind to try to upgrade hibernate OGM.


On Thu, Oct 17, 2013 at 4:57 PM, Sanne Grinovero wrote:

> Hi all,
> it looks like I will be very busy on Search and some more Infinispan
> integrations in the coming couple of months, but there are some very
> exciting things that I would love to see in OGM soon, and since I
> heard there is a lot of excited people out there waiting for this too,
> this is your chance to grab some more glory.
>
> As you know we have several GridDialects, one of the first one was
> supporting Infinispan but only in "embedded mode".
>
> Embedded mode was the first choice because it's easier, and also because:
>  - it supports transactions
>  - had some form of query capability (although we never used it)
>  - lowest latency, assuming your data set is reasonable
>
> But people looking at OGM are especially fascinated by the idea to use
> it in a more traditional architecture, which implies having a
> "database" as a separate independent service.
>
> Infinispan 6.0 is almost ready, and thanks to Gunnar includes a bit of
> OGM in its DNA to support queries defined from a remote client (Hot
> Rod client).
>
> I think it would be terrific if someone could start hacking on a
> HotRodDialect, and start writing tests to stress this new query
> capability; specifically I had the Gunnar - Davide team in mind if
> they can :-)
>
> We'll have to ignore transactions for now, I guess it could be
> considered like we do with MongoDB: make it clear the backend is not
> transactional in the docs.
>
> Timing-wise, if we could have a prototype using HQL queries very very
> soon, that would be a great help to the Infinispan team as it would
> validate the new feature; this idea of mine is probably too late as
> Infinispan is already at CR2 phase (tomorrow) but you might be able to
> put some basic checks in place on time?
>
> Second priority - also relatively urgent - is to move on to latest ORM
> version, so that possible complexities can be softened in ORM before
> 4.3 is declared Final.. it's still using the outdatet 4.2.0.CR1 !?
> We should get it to work on WildFly quickly.
>
> 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] support for remote grids

[Davide D';Alto]

> I also don't mind to try to upgrade hibernate OGM.
Sorry I meant ORM


On Thu, Oct 17, 2013 at 5:12 PM, Davide D'Alto wrote:

> I can take the HotRod dialect task since I've already some experience with
> datastore integration for OGM.
> I also don't mind to try to upgrade hibernate OGM.
>
>
>
> On Thu, Oct 17, 2013 at 4:57 PM, Sanne Grinovero wrote:
>
>> Hi all,
>> it looks like I will be very busy on Search and some more Infinispan
>> integrations in the coming couple of months, but there are some very
>> exciting things that I would love to see in OGM soon, and since I
>> heard there is a lot of excited people out there waiting for this too,
>> this is your chance to grab some more glory.
>>
>> As you know we have several GridDialects, one of the first one was
>> supporting Infinispan but only in "embedded mode".
>>
>> Embedded mode was the first choice because it's easier, and also because:
>>  - it supports transactions
>>  - had some form of query capability (although we never used it)
>>  - lowest latency, assuming your data set is reasonable
>>
>> But people looking at OGM are especially fascinated by the idea to use
>> it in a more traditional architecture, which implies having a
>> "database" as a separate independent service.
>>
>> Infinispan 6.0 is almost ready, and thanks to Gunnar includes a bit of
>> OGM in its DNA to support queries defined from a remote client (Hot
>> Rod client).
>>
>> I think it would be terrific if someone could start hacking on a
>> HotRodDialect, and start writing tests to stress this new query
>> capability; specifically I had the Gunnar - Davide team in mind if
>> they can :-)
>>
>> We'll have to ignore transactions for now, I guess it could be
>> considered like we do with MongoDB: make it clear the backend is not
>> transactional in the docs.
>>
>> Timing-wise, if we could have a prototype using HQL queries very very
>> soon, that would be a great help to the Infinispan team as it would
>> validate the new feature; this idea of mine is probably too late as
>> Infinispan is already at CR2 phase (tomorrow) but you might be able to
>> put some basic checks in place on time?
>>
>> Second priority - also relatively urgent - is to move on to latest ORM
>> version, so that possible complexities can be softened in ORM before
>> 4.3 is declared Final.. it's still using the outdatet 4.2.0.CR1 !?
>> We should get it to work on WildFly quickly.
>>
>> 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] Transactions in Neo4j datastore

[Davide D';Alto]

The isNeo4j() is just a trick so that the user does not have to set a
property. I'm also not totally happy about it

> Neo4j seems to allow for this via the TransactionManagerProvider SPI.
Unfortunately one isn't in control of instantiating such providers, though.
So one would have to do some hackery using a static variable, ThreadLocal
or similar to pass in the JtaPlatform. WDYT, would that make sense?

This was actually the original intention. I've tried to hack a bit in the
interface but in the end there was always something not working (at some
point I was able to inject the JtaPlatform in Neo4j but I don't remember
how to do it). In the end this one was the easiest one to implement.

I'm happy if you want to explore this solution but I think we should talk
with the Neo4j guys first to see if it is possible to add an option to pass
an already created object.
It seems easier and it doesn't requires hacks.



On Fri, Oct 25, 2013 at 12:40 PM, Gunnar Morling wrote:

> Hi Davide,
>
> I'm wondering why instead of creating Neo4jJtaPlatform we don't provide
> the TransactionManager as retrieved from ORM's JtaPlatform to Neo4j (as we
> e.g. do for ISPN)? I find the isNeo4j() code in ogm-core a bit
> discomforting.
>
> Neo4j seems to allow for this via the TransactionManagerProvider SPI.
> Unfortunately one isn't in control of instantiating such providers, though.
> So one would have to do some hackery using a static variable, ThreadLocal
> or similar to pass in the JtaPlatform. WDYT, would that make sense?
>
> --Gunnar
>
>
>
>
> 2013/3/13 Davide D'Alto 
>
>> Well...I don't have alternative at the moment.
>>
>> I think we could keep it as it is now and wait for some feedback from the
>> users.
>>
>> On Mon, Mar 4, 2013 at 1:17 PM, Emmanuel Bernard 
>> wrote:
>> > Do you have an alternative in mind?
>> >
>> > My understanding is that if you write a Neo4J JtaPlatform, then the
>> > transaction will be started:
>> >
>> > - if the transaction is manually started by the wrapping code
>> > - if someone uses Session.beginTransaction() or
>> >   EntityManager.getTransaction().begin()
>> >
>> > You wanted the Neo4J transaction to be started if @Transactional is
>> > added to a CDI bean? I'd say that's the job of the Neo4J team to amke
>> > sure that one works, no?
>> >
>> > If we can find a better solution that would be nice but I'm not sure I
>> > understand the problem :)
>> >
>> > Emmanuel
>> >
>> > On Mon 2013-02-25 15:08, Davide D'Alto wrote:
>> >> Hi,
>> >> I'm working at the integration between OGM and Neo4j.
>> >>
>> >> Neo4j is fully transactional and it requires to open a transaction
>> >> before the execution of any operation on the DB.
>> >> To integrate this mechanism with OGM I've created the class
>> >> Neo4jJtaPlatform.java[1] that extends AbstractJtaPlatform and it's
>> >> registered using the configuration parameter
>> >> hibernate.transaction.jta.platform
>> >> If I'm correct, while this solution is working, it requires the
>> >> application to manage transactions using the Neo4j transaction
>> >> manager. Are there alternatives to this approach?
>> >>
>> >> The related pull request can be found at
>> >> https://github.com/hibernate/hibernate-ogm/pull/132
>> >>
>> >> Thanks,
>> >> Davide
>> >>
>> >> [1]
>> https://github.com/DavideD/hibernate-ogm/blob/2b6588998673bce8a9ccd973f693d7fe091e8c9c/hibernate-ogm-neo4j/src/main/java/org/hibernate/ogm/dialect/neo4j/Neo4jJtaPlatform.java
>> >> ___
>> >> 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] Build time

[Davide D';Alto]

> a. Provide a -Dminimal flag to run in case 1.
For the backends, I'm fine in using mvn -pl {module}

> b. Provide a -Dcomplete flag to run in case 3.
>> One shortcoming in Maven is though that one - afaik - can't enable
profiles using several properties. So having -Dcomplete (or
-DskipAllExpensive if we want to default the other way around) would mean
that we can't skip single things specifically (e.g. only skip docs). If
we're ok with loosing that granular level of control we can try that.
I'm ok with that, if we are using the complete flag we probably don't want
to exclude stuff.
Unless I'm missing something.

> export mvnFast = "mvn -DskipITs -DskipDocs -DskipDistro"

I don't have major preferences, I think a profile "fast" would be nice:
mvn -Pfast

but an alias is as good for me.

> Note that this leaves open what 'mvn clean install' should do.

I don't mind what we include (ideally everything) but it should
successfully build without additional steps.


On Thu, Nov 28, 2013 at 9:45 AM, Gunnar Morling wrote:

> Answers inline.
>
> 2013/11/28 Emmanuel Bernard 
>
> > My machine is in a poor state. But still, the default mvn install took
> > more than 7 minutes.
> > For info the minimal build takes 3:20 (4:30 with the integration tests).
> >
> > We have added a few mechanisms over time on OGM:
> >
> > * modules depending on an external DB are skipped if SOMEDB_HOSTNAME is
> >   not set
> >
> * skipDocs which skips documentation and JavaDocs (JavaDocs take a lot
> >   of time on my machine)
> > * skipITs which skips the integration tests
> > * skipDistro which skips the distribution
> >
> > While each individual mechanism serves a purpose, it ends up serving
> > everyone badly. Minimalarians complain about the myriad of flags to
> > write each time. Safarians complain that if they forget
> > COUCHDB_HOSTNAME, the distribution will simply not contain it.
> >
> > I think there are four main use cases
> >
> > 1. run the test suite for one specific db + rebuild core as things might
> >have changed
> > 2. run the minimal test suite to make sure things compile and work
> > 3. run a full test on every backend and build the distribution for a
> >release
> > 4. other cases
> >
> > I suspect the % of time per use case is as follow (your mileage may
> > vary):
> >
> > 1. 45%
> > 2. 45%
> > 3. 1%
> > 4. 9%
> >
> > But when you are in case 3. you absolutely must be sure everything run
> > and no module is skipped.
> >
> > Here is a proposal
> >
> > a. Provide a -Dminimal flag to run in case 1.
> >
>
> You still would have to specify the backend you want to build, right? How
> would such flag be used then?
>
> That's how I cover that case:
>
> mvn clean install -pl {couchdb|mongodb|...}
>
> This is fast as there is no docs, dist etc. included in these modules. To
> optionally also build core I do:
>
> mvn clean install -pl {couchdb|mongodb|...} -am (for _a_lso _m_aking
> dependencies)
>
> Would a custom flag improve upon this?
>
>
> b. Provide a -Dcomplete flag to run in case 3.
> >
>
> We might do that.
>
> One shortcoming in Maven is though that one - afaik - can't enable profiles
> using several properties. So having -Dcomplete (or -DskipAllExpensive if we
> want to default the other way around) would mean that we can't skip single
> things specifically (e.g. only skip docs). If we're ok with loosing that
> granular level of control we can try that.
>
>
> > c. Provide a script to do 2. I suspect case 2. can only be done with a
> >custom script or by moving to Gradle. For various reasons, I don't
> want
> >us to move to Gradle at this stage.
> >
>
> How about
>
> d. Use an alias for all skip options:
>
> export mvnFast = "mvn -DskipITs -DskipDocs -DskipDistro"
>
> This gives a quick build in one command and still allows for fine
> granularity if needed.
>
>
> > Everyone OK with doing a. and b.
> > The problem with c. is that making a cross platform script requires time
> > but we could make it work for us at least.
> >
> > Note that this leaves open what 'mvn clean install' should do.
> >
>
> To me it should include everything by default (hence I'd prefer
> -DskipAllExpensive over -Dcomplete) but if a majority of you guys prefer
> another behavior I'd adapt.
>
>
> >
> > Thoughts?
> >
> > Emmanuel
> > ___
> > 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] Precedence of options specified on different levels

[Davide D';Alto]

 If I understand correctly, What you are suggesting instead, it is to have
two different names for the same property (), defaultHost in the
persistence.xml and host in the API, this means that I have to know how to
call a property based on the place where I want to set it. This is
confusing for me.

If a a user sets the same property in two different places he will for sure
know that one value will override the other at some point. Why would he do
that otherwise?




On Tue, Dec 3, 2013 at 4:48 PM, Gunnar Morling  wrote:

> Thanks, Davide.
>
> 2013/12/3 Davide D'Alto 
>
>> It looks good to me.
>>
>
> Ok.
>
> > I first didn't like that but I came to think it makes sense, if the
>> property name conveys that semantics, e.g. "defaultAssociationStorageMode".
>>
>> I don't think it's necessary to use the prefix "default". For me it is
>> just a setting that it is overridden by something else in some situations,
>> the same as an annotation is declared at the same time on the class and on
>> an attribute.
>>
>
> From what I can say it's reasonable for a user to expect that properties
> given via persistence.xml or similar actually do apply and are not
> overridden by code or annotations.
>
> Take the MongoDB "host" as example, here we have an internal constant with
> a default but the user can set "hibernate.ogm.mongodb.host" and this
> setting applies. That's different from the proposed algorithm where the
> property really would only be used as fallback if not configuration is
> given by means of annotations or API.
>
> Thus I think it makes sense to make this semantics transparent via the
> "default..." prefix in the property name.
>
>
>>
>> Davide
>>
>>
>>
>> On Tue, Dec 3, 2013 at 9:48 AM, Gunnar Morling wrote:
>>
>>> Hi,
>>>
>>> In the context of embedded associations for CouchDB [1], I'm working on
>>> support for configuring the association storage mode using our new option
>>> system [2]. I can see the following "axes" of configuration here:
>>>
>>> * via annotation
>>>   - on an association property
>>>   - on a type
>>> * via the option API
>>>   - on an association property
>>>   - on a type
>>>   - on the global level
>>> * via a configuration property as given via OgmConfiguration,
>>> persistence.xml etc.
>>> * on super-types
>>>   - via annotations or API
>>>   - on the property or entity level
>>>
>>> I'm looking now for a sensible and comprehensible algorithm for taking
>>> these sources of configuration into account and determining the effective
>>> setting for a given association. This could be one way:
>>>
>>> 1) check API
>>>   a) look for a setting given via the programmatic API for the given
>>> property
>>>   b) if the property is not configured, look for a setting given for the
>>> entity
>>>   c) if the entity itself is not configured, repeat a) and b) iteratively
>>> on super-types if present
>>>   d) if no type from the hierarchy is configured look for the global
>>> setting
>>>
>>> 2) check annotations
>>>   if no configuration could be found in 1), do the same for annotations,
>>> i.e.
>>>   a) look for configuration on the given property
>>>   b) look for configuration on the given entity
>>>   c) repeat a) and b) iteratively on super-types if present
>>>
>>> 3) take default value given via OgmConfiguration/persistence.xml etc.
>>>
>>> This algorithm ensures that:
>>> * API configuration always takes precedence over annotation
>>> configuration;
>>> e.g. if a super-type is configured via the API or the setting is given on
>>> the API global level, any annotations are ignored
>>> * "More local" configuration takes precedence; i.e. a type's own
>>> configuration wins over configuration from super-types, property-level
>>> configuration wins over entity-level configuration
>>>
>>> Note that any setting given via OgmConfiguration/persistence.xml would be
>>> handled as last fallback option, i.e. any configuration given via
>>> annotations or the API would take precedence over that. I first didn't
>>> like
>>> that but I came to think it makes sense, if the property name conveys
>>> that
>>> semantics, e.g. "defaultAssociationStorageMode".
>>>
>>> Any other thoughts or alternative approaches around this?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1] https://hibernate.atlassian.net/browse/OGM-389
>>> [1] https://hibernate.atlassian.net/browse/OGM-208
>>> ___
>>> 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] Store-specific constants

[Davide D';Alto]

> Our question is, should now that we have the Option API and with it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?

Yes, +1



On Wed, Dec 11, 2013 at 5:08 PM, Gunnar Morling wrote:

> Hi,
>
> Davide brought up an interesting issue while reviewing a PR around the OGM
> backend for CouchDB [1].
>
> This PR makes use of the new Option API and allows to configure
> CouchDB-specific settings in a safe way. For that purpose each dialect
> needs to provide a sub-class of DatastoreConfiguration which is then passed
> to configureDatastore() like this:
>
> OgmSessionFactory factory = ...;
> factory.configureDatastore( CouchDB.class )
> .associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
>
> Now I had defined a constant on CouchDB for the property name for setting
> the association storage type via OgmConfiguration, not being fully aware of
> the existing interface Environment which defines some other constants such
> as host name property etc.
>
> Our question is, should now that we have the Option API and with it
> store-specific DatastoreConfiguration types, the previously used
> Environment interfaces be removed and their constants moved to the
> corresponding DatastoreConfiguration type?
>
> I think that'd make sense, also having in mind that we might expose
> settings configured via OgmConfiguration via an equivalent global option at
> some point. Also having distinct class names will be beneficial in polyglot
> persistence scenarios where one needs to configure several stores.
>
> What do others think?
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-ogm/pull/261
> ___
> 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] Precedence of options specified on different levels

[Davide D';Alto]

> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.

I agree with emmanuel on this one.

I think I would be surprise to see that the annotation that should override
the "default" value for the class
overrides also the specific value for the properties.



On Mon, Dec 16, 2013 at 10:06 AM, Gunnar Morling wrote:

> 2013/12/13 Emmanuel Bernard 
>
> > So currently in the pull request, we now have the following
> >
> > 1. property > entity > global
> > 2. for each level in 1., programmatic API beats annotation
> >
> > These are simple rules to understand and all it good.
> >
> > Now Gunnar tried to handle class inheritance, ie superclasses and
> > overridden methods.
> > And we do differ in what we consider the natural rules (or what it
> > should be).
> >
> > Here is how I think the rules should be:
> >
> > 1. property > entity > global
> > 2. for each level in 1., subclass > superclass and overridden method >
> > parent method
> > 3. for each level (in 1 and 2), programmatic API beats annotation
> >
> > Here is how Gunnar thinks the rules should be:
> >
> > 1. metadata on a class > metadata on a superclass (whether it is on a
> > property or the class)
> > 2. for each hierarchy level, property > entity > global
> > 3. for each level in 1 and 2, programmatic API beats annotation
> >
> > In more concrete words,
> >
> > @Option(1)
> > class A {
> > @Option(2)
> > public String getMe() {return null;}
> > }
> >
> > @Option(3)
> > class B extends A {
> > @Override
> > public String getMe() {return null;}
> > }
> >
> > In my world, B.getMe has Options(2).
> > In Gunnar's world, B.getMe() has @Option(3).
> >
>
> Thanks for the clear explanation and example for the issue.
>
>
> > To me, a property level is always more specific than an entity, hence my
> > interpretation. If someone has set a value on a given property, it would
> > be dangerous to be "globally" overridden by a subclass.
> >
> > Thoughts?
> >
>
> What would be "dangerous" in this case?
>
> I think for the author of B it's helpful to be able to change the defaults
> for the entire class. Also for a reader of B its simpler to grasp the
> applying configuration with my proposal, because the entire "truth" about
> the annotation config can be found in B, you don't have to look into any
> super-classes. So to me, that's more along the lines of the principle of
> least surprise.
>
> That said I'm not sure whether really one option is more "natural" than the
> other, seems like it can be defined either that way or the other.
>
> Davide, Sanne, Guillaume, others, what's your take on this?
>
>
> >
> > Emmanuel
> >
> > On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > > Hi,
> > >
> > > In the context of embedded associations for CouchDB [1], I'm working on
> > > support for configuring the association storage mode using our new
> option
> > > system [2]. I can see the following "axes" of configuration here:
> > >
> > > * via annotation
> > >   - on an association property
> > >   - on a type
> > > * via the option API
> > >   - on an association property
> > >   - on a type
> > >   - on the global level
> > > * via a configuration property as given via OgmConfiguration,
> > > persistence.xml etc.
> > > * on super-types
> > >   - via annotations or API
> > >   - on the property or entity level
> > >
> > > I'm looking now for a sensible and comprehensible algorithm for taking
> > > these sources of configuration into account and determining the
> effective
> > > setting for a given association. This could be one way:
> > >
> > > 1) check API
> > >   a) look for a setting given via the programmatic API for the given
> > > property
> > >   b) if the property is not configured, look for a setting given for
> the
> > > entity
> > >   c) if the entity itself is not configured, repeat a) and b)
> iteratively
> > > on super-types if present
> > >   d) if no type from the hierarchy is configured look for the global
> > setting
> > >
> > > 2) check annotations
> > >   if no configuration could be found in 1), do the same for
> annotations,
> > > i.e.
> > >   a) look for configuration on the given property
> > >   b) look for configuration on the given entity
> > >   c) repeat a) and b) iteratively on super-types if present
> > >
> > > 3) take default value given via OgmConfiguration/persistence.xml etc.
> > >
> > > This algorithm ensures that:
> > > * API configuration always takes precedence over annotation
> > configuration;
> > > e.g. if a super-type is configured via the API or the setting is given
> on
> > > the API global level, any annotations are ignored
> > > * "More local" configuration takes precedence; i.e. a type's own
> > > configuration wins over configuration from super-types, property-level
> > > configuration wins over entity-level configuration
>

Re: [hibernate-dev] [OGM] Public packages of datastore modules

[Davide D';Alto]

I can work on this today and start to plan the release for Wednesday.

I don't think this change should block the next release though.

It would also be nice to include this:
https://github.com/hibernate/hibernate-ogm/pull/282
so that people can actually use the enitty manager to create queries



On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling wrote:

> Hi,
>
> One thing I'd like to address before doing the next OGM release is the
> structure of public packages in the datastore-specific modules.
>
> Currently we have the following structure:
>
> * org.hibernate.ogm.datastore.
> * org.hibernate.ogm.dialect.
> * org.hibernate.ogm.logging.
> ...
>
> I think it makes sense to pull the datastore-specific package up one level,
> moving all the types of a backend under one shared super-package. So it
> would like this instead:
>
> * org.hibernate.ogm..datastore
> * org.hibernate.ogm..dialect
> * org.hibernate.ogm..logging
> ...
>
> The reason I'm bringing this up is that we're introducing new user-exposed
> types with that release: the store identifier types (MongoDB, CouchDB etc.)
> and their properties class (MongoDBProperties, CouchDBProperties etc.). So
> if we agree to do this change it would be good to do it now before having
> to move these public types later on.
>
> Another question is how to differentiate between public and internal
> packages, but I think we can discuss this later on, as a change would only
> affect internal packages. Emmanuel and I couldn't agree on a best approach
> when discussing it shortly, so this might need some more time :)
>
> Any thoughts?
>
> --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] [OGM] Public packages of datastore modules

[Davide D';Alto]

> Since you mention users as a reason for this change, I've to admit that I
don't see how it helps users.

I think as well that it won't impact the user so much but It seems more
natural that way and I've heard the suggestion to change it from at least 3
different people (including myself).
That's the reason I think we should change it but I don't see it as
something that should delay a release.

> I'd move things to .impl for the private ones, leaving all others as they
are. That should also simplify for example a filtering rule for the javadoc
generation.

+1

>> I can work on this today and start to plan the release for Wednesday.
> Hum, tbh. I'm not sure whether I'll be done with the doc updates by
Wednesday.


Would next Wednesday be a more suitable date? I would prefer not to
postpone this any further


.


On Mon, Feb 10, 2014 at 2:15 PM, Gunnar Morling wrote:

> 2014/2/10 Davide D'Alto 
>
>> I can work on this today and start to plan the release for Wednesday.
>>
>
> Hum, tbh. I'm not sure whether I'll be done with the doc updates by
> Wednesday.
>
> There is also OGM-392 (support for optimistic locking in CouchDB) which
> I'd love to squeeze in as the current solution encourages non-canonical
> usage of CouchDB (we don't take advantage of the built-in "_rev" property).
>
>
>>
>> I don't think this change should block the next release though.
>>
>> It would also be nice to include this:
>> https://github.com/hibernate/hibernate-ogm/pull/282
>> so that people can actually use the enitty manager to create queries
>>
>
> +1
>
>>
>>
>>
>> On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling wrote:
>>
>>> Hi,
>>>
>>> One thing I'd like to address before doing the next OGM release is the
>>> structure of public packages in the datastore-specific modules.
>>>
>>> Currently we have the following structure:
>>>
>>> * org.hibernate.ogm.datastore.
>>> * org.hibernate.ogm.dialect.
>>> * org.hibernate.ogm.logging.
>>> ...
>>>
>>> I think it makes sense to pull the datastore-specific package up one
>>> level,
>>> moving all the types of a backend under one shared super-package. So it
>>> would like this instead:
>>>
>>> * org.hibernate.ogm..datastore
>>> * org.hibernate.ogm..dialect
>>> * org.hibernate.ogm..logging
>>> ...
>>>
>>> The reason I'm bringing this up is that we're introducing new
>>> user-exposed
>>> types with that release: the store identifier types (MongoDB, CouchDB
>>> etc.)
>>> and their properties class (MongoDBProperties, CouchDBProperties etc.).
>>> So
>>> if we agree to do this change it would be good to do it now before having
>>> to move these public types later on.
>>>
>>> Another question is how to differentiate between public and internal
>>> packages, but I think we can discuss this later on, as a change would
>>> only
>>> affect internal packages. Emmanuel and I couldn't agree on a best
>>> approach
>>> when discussing it shortly, so this might need some more time :)
>>>
>>> Any thoughts?
>>>
>>> --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] Getting notified when session factory is completely set up

[Davide D';Alto]

> Yes, that helps indeed. Implementing my validation routine in such an
observer works. I guess if needed, I even could implement support for the
suggested service contract in OGM with help of an observer.

In OGM, we used to have a SessionFactoryObserver but we removed it in favor
of the SessionFactoryServiceInitiator.
https://hibernate.atlassian.net/browse/OGM-299




On Tue, Feb 11, 2014 at 10:05 AM, Gunnar Morling wrote:

> 2014/2/11 Hardy Ferentschik 
>
> > Hi,
> >
> > not sure whether this could work in your use case, but in Search we use a
> > SessionFactoryObserver.
> > We register the observer in Integrator#integrate with the
> > SessionFactoryImplementor.
> > Once the SessionFactory is completely build you get a callback into
> > SessionFactoryObserver#sessionFactoryCreated().
> >
> > In Search we had the case that we did not want to complete bootstrapping
> > at the integrator phase. Instead we defer
> > this until the SessionFactory is completely build.
> >
> > Hope it helps.
> >
>
> Yes, that helps indeed. Implementing my validation routine in such an
> observer works. I guess if needed, I even could implement support for the
> suggested service contract in OGM with help of an observer.
>
> Thanks!
>
>
> >
> > --Hardy
> >
> >
> >
> > On 11 Jan 2014, at 09:38, Gunnar Morling  wrote:
> >
> > > Hi,
> > >
> > > Is there a way for services (living in the SF-scoped registry) to get
> > > notified when the session factory has been set up and perform some
> action
> > > using that completely initialized factory?
> > >
> > > Upon invocation of initiateService() of SessionFactoryServiceInitiator
> > > implementations, the passed factory is still under construction (the
> call
> > > originates from SessionFactoryImpl), so I can't access all
> members.
> > > The same holds true for the StartStoppable contract in OGM which also
> > sees
> > > a session factory under construction.
> > >
> > > Now I could store the passed reference in a field and execute the
> > required
> > > logic (some sort of validation) later on. I only have no meaningful
> hook
> > to
> > > trigger such action exactly once. So I'd have to manage a flag to make
> > sure
> > > the action is only performed once.
> > >
> > > Is there a better way to achieve this?
> > >
> > > Would it make sense to provide an additional contract to notify
> services
> > > about session factory lifecycle events:
> > >
> > >public interface SessionFactoryLifecycleAware extends Service {
> > >
> > >void onSessionFactoryLifecycleEvent(SessionFactoryImplementor
> sfi,
> > > Event event);
> > >
> > >public enum Event { POST_START, PRE_STOP }
> > >}
> > >
> > > ?
> > >
> > > 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

[hibernate-dev] Fwd: [OGM] Public packages of datastore modules

[Davide D';Alto]

> a) it adds many empty packages which seem user-exposed but actually
aren't (org.hibernate.ogm.logging, org.hibernate.ogm.logging.
mongodb) and b) it makes it cumbersome to structure impl-internal stuff
into sub-packages (have a look at the CouchDB module [1] to see what I
mean).

I think I've missed it, what is it your suggestion for internal packages?



On Mon, Feb 10, 2014 at 4:09 PM, Sanne Grinovero wrote:

> On 10 February 2014 14:52, Gunnar Morling  wrote:
> > 2014/2/10 Sanne Grinovero 
> >>
> >> On 10 February 2014 12:32, Davide D'Alto  wrote:
> >> > I can work on this today and start to plan the release for Wednesday.
> >> >
> >> > I don't think this change should block the next release though.
> >> >
> >> > It would also be nice to include this:
> >> > https://github.com/hibernate/hibernate-ogm/pull/282
> >> > so that people can actually use the enitty manager to create queries
> >> >
> >> >
> >> >
> >> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling
> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> One thing I'd like to address before doing the next OGM release is
> the
> >> >> structure of public packages in the datastore-specific modules.
> >> >>
> >> >> Currently we have the following structure:
> >> >>
> >> >> * org.hibernate.ogm.datastore.
> >> >> * org.hibernate.ogm.dialect.
> >> >> * org.hibernate.ogm.logging.
> >> >> ...
> >> >>
> >> >> I think it makes sense to pull the datastore-specific package up one
> >> >> level,
> >> >> moving all the types of a backend under one shared super-package. So
> it
> >> >> would like this instead:
> >> >>
> >> >> * org.hibernate.ogm..datastore
> >> >> * org.hibernate.ogm..dialect
> >> >> * org.hibernate.ogm..logging
> >> >> ...
> >> >>
> >> >> The reason I'm bringing this up is that we're introducing new
> >> >> user-exposed
> >> >> types with that release: the store identifier types (MongoDB, CouchDB
> >> >> etc.)
> >> >> and their properties class (MongoDBProperties, CouchDBProperties
> etc.).
> >> >> So
> >> >> if we agree to do this change it would be good to do it now before
> >> >> having
> >> >> to move these public types later on.
> >>
> >> Since you mention users as a reason for this change, I've to admit
> >> that I don't see how it helps users.
> >> Personally I think it's quite helpfull to have the package to help me
> >> quickly identify which dialects I have available;
> >
> >
> > That's my thinking as well, but how do the intermediary "datastore",
> > "dialect" etc. packages (at a higher level than the actual datastore
> > package) help to achieve this?
> >
> > To me, packages should be organized by the most important criteria first,
> > and that's IMO the type of datastore here. Thus I think it should be
> > org.hibernate.ogm.mongodb.* for everything MongoDB instead of
> > org.hibernate.ogm.*.mongodb. Why have these rather technical packages in
> > between?
>
> I understand that you like that better, but we need to figure if
> that's an objective statement: dialects in Hibernate ORM don't work
> like that, and people are used to the current approach:
>
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch03.html#configuration-optional-dialects
>
> My impression is that ORM users are familiar with the concept of
> "dialect", hence they know they are searching for a dialect which does
> make it quite straight forward to go for something in
>
> org.hibernate.dialect
>
> For example it's
>  > org.hibernate.dialect.H2Dialect
> and not
> > org.hibernate.h2.Dialect
> and also it's not
> > h2.dialect.hibernate
>
> I realize the ORM is slightly different as it has just one class,
> still that's what people are used to in terms of dialects.
>
> "most important criteria first, as you say.." ;-)
>
> Maybe 100% of our users would disagree with the ORM naming choice if
> asked about it, but I've seen no complains so either that's not true
> or nobody cares enough, which is why I'm still not persuaded on this
> being worth of our time to change

Re: [hibernate-dev] Getting notified when session factory is completely set up

[Davide D';Alto]

> I can "inject" the SF into a DatastoreProvider by having it implement
said StartStoppable contract. But as pointed out before the SF is not yet
completely initialized at this point. So I e.g. can't access the entity
persisters.

Isn't the SessionFactory already created by the time
StartStoppable#startService is called?


On Tue, Feb 11, 2014 at 11:26 AM, Gunnar Morling wrote:

> 2014/2/11 Davide D'Alto 
>
>> > Yes, that helps indeed. Implementing my validation routine in such an
>> observer works. I guess if needed, I even could implement support for the
>> suggested service contract in OGM with help of an observer.
>>
>> In OGM, we used to have a SessionFactoryObserver but we removed it in
>> favor of the SessionFactoryServiceInitiator.
>> https://hibernate.atlassian.net/browse/OGM-299
>>
>>
> But do we have a DatastoreProvider which actually makes use of the SF?
>
> I can "inject" the SF into a DatastoreProvider by having it implement said
> StartStoppable contract. But as pointed out before the SF is not yet
> completely initialized at this point. So I e.g. can't access the entity
> persisters.
>
> I couldn't find any "real" implementation of StartStoppable (besides a
> testing one); it might actually make sense to re-implement the support for
> this contract using an observer, which would expose a fully-initialized SF
> to such implementations.
>
> The problem I'm having atm. only relates to CouchDB, so for the time being
> I think I'm going to add an observer just to this module.
>
>
>
>>
>>
>> On Tue, Feb 11, 2014 at 10:05 AM, Gunnar Morling wrote:
>>
>>> 2014/2/11 Hardy Ferentschik 
>>>
>>> > Hi,
>>> >
>>> > not sure whether this could work in your use case, but in Search we
>>> use a
>>> > SessionFactoryObserver.
>>> > We register the observer in Integrator#integrate with the
>>> > SessionFactoryImplementor.
>>> > Once the SessionFactory is completely build you get a callback into
>>> > SessionFactoryObserver#sessionFactoryCreated().
>>> >
>>> > In Search we had the case that we did not want to complete
>>> bootstrapping
>>> > at the integrator phase. Instead we defer
>>> > this until the SessionFactory is completely build.
>>> >
>>> > Hope it helps.
>>> >
>>>
>>> Yes, that helps indeed. Implementing my validation routine in such an
>>> observer works. I guess if needed, I even could implement support for the
>>> suggested service contract in OGM with help of an observer.
>>>
>>> Thanks!
>>>
>>>
>>> >
>>> > --Hardy
>>>
>>> >
>>> >
>>> >
>>> > On 11 Jan 2014, at 09:38, Gunnar Morling  wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Is there a way for services (living in the SF-scoped registry) to get
>>> > > notified when the session factory has been set up and perform some
>>> action
>>> > > using that completely initialized factory?
>>> > >
>>> > > Upon invocation of initiateService() of
>>> SessionFactoryServiceInitiator
>>> > > implementations, the passed factory is still under construction (the
>>> call
>>> > > originates from SessionFactoryImpl), so I can't access all
>>> members.
>>> > > The same holds true for the StartStoppable contract in OGM which also
>>> > sees
>>> > > a session factory under construction.
>>> > >
>>> > > Now I could store the passed reference in a field and execute the
>>> > required
>>> > > logic (some sort of validation) later on. I only have no meaningful
>>> hook
>>> > to
>>> > > trigger such action exactly once. So I'd have to manage a flag to
>>> make
>>> > sure
>>> > > the action is only performed once.
>>> > >
>>> > > Is there a better way to achieve this?
>>> > >
>>> > > Would it make sense to provide an additional contract to notify
>>> services
>>> > > about session factory lifecycle events:
>>> > >
>>> > >public interface SessionFactoryLifecycleAware extends Service {
>>> > >
>>> > >void onSessionFactoryLifecycleEvent(SessionFactoryImplementor
>>> sfi,
>>> > > Event event);
>>> > >
>>> > >public enum Event { POST_START, PRE_STOP }
>>> > >}
>>> > >
>>> > > ?
>>> > >
>>> > > 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

[hibernate-dev] Extract some methods form AbtractEntityManagerImpl

[Davide D';Alto]

Hi,
in OGM I'm reusing some of the methods in AbstractEntityMangerImpl, the
problem is that their scope is protected and I had to move OgmEntityManager
from the original package to *org.hibernate.jpa.spi*

Is it possible to expose these methods in some way, so that I can move
OgmEntityManager to the original package?

The methods are:
- applySavedSettings(NamedQueryDefinition namedQueryDefinition, QueryImpl
jpaQuery);
- resultClassChecking(Class resultType, NamedSQLQueryDefinition
namedQueryDefinition);
- applyProperties(Query query); (this is private but I've copied and paste
it from ORM to OGM)

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

[hibernate-dev] [OGM] Ogm documentation does not build completly

[Davide D';Alto]

Hi.
I've noticed that when I run the build of OGM the documentation is not
completly built.
The part releated to the single datastores is missing.

It works on Jenkins.

Does it happen only to me?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Ogm documentation does not build completly

[Davide D';Alto]

It seems to work fine if I remove the "module/" from the include part in
the datastore-providers.asciidoc,
for example from

*include::modules/infinispan.asciidoc[]*
to
*include::infinispan.asciidoc[]*

I will try again tomorrow.
Do you think the Java or maven version might be on issue? Out of curiosity,
which version are you using?


On Mon, Feb 17, 2014 at 9:46 PM, Gunnar Morling wrote:

> Same here, all chapters are there as expected.
>
> As a starting point for analysis, does the assembled DocBook file
> under documentation/manual/target/docbook/en-US/master.xml contain all the
> chapters? If not it seems to be a problem with Asciidoc.
>
>
> 2014/2/17 Guillaume SCHEIBEL 
>
>> Hi Davide,
>>
>> I've just fetch the master and the documentation built without any
>> problem.
>>
>> Guillaume
>>
>>
>> 2014-02-17 20:18 GMT+01:00 Davide D'Alto :
>>
>> > Hi.
>> > I've noticed that when I run the build of OGM the documentation is not
>> > completly built.
>> > The part releated to the single datastores is missing.
>> >
>> > It works on Jenkins.
>> >
>> > Does it happen only to me?
>> > ___
>> > 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] Ogm documentation does not build completly

[Davide D';Alto]

Thanks for the help.

I still haven't found  the reason but I'm investigating.
Upgrade the plugins did not help.


On Mon, Feb 17, 2014 at 10:10 PM, Gunnar Morling wrote:

> Apache Maven 3.0.3 and Java 1.7.0_45.
>
> I don't think it's related to that. Do you see any error in the output
> from AsciiDoctor? Maybe there is some kind of debug or verbose option? You
> also could try updating to the latest version of asciidoctor-maven-plugin
> (0.1.4).
>
>
> 2014/2/17 Guillaume SCHEIBEL 
>
>> java version "1.7.0_51" and  Maven 3.1.1
>>
>>
>>
>> 2014-02-17 22:51 GMT+01:00 Davide D'Alto :
>>
>> It seems to work fine if I remove the "module/" from the include part in
>>> the datastore-providers.asciidoc,
>>> for example from
>>>
>>> *include::modules/infinispan.asciidoc[]*
>>> to
>>> *include::infinispan.asciidoc[]*
>>>
>>> I will try again tomorrow.
>>> Do you think the Java or maven version might be on issue? Out of
>>> curiosity, which version are you using?
>>>
>>>
>>> On Mon, Feb 17, 2014 at 9:46 PM, Gunnar Morling wrote:
>>>
>>>> Same here, all chapters are there as expected.
>>>>
>>>> As a starting point for analysis, does the assembled DocBook file
>>>> under documentation/manual/target/docbook/en-US/master.xml contain all the
>>>> chapters? If not it seems to be a problem with Asciidoc.
>>>>
>>>>
>>>> 2014/2/17 Guillaume SCHEIBEL 
>>>>
>>>>> Hi Davide,
>>>>>
>>>>> I've just fetch the master and the documentation built without any
>>>>> problem.
>>>>>
>>>>> Guillaume
>>>>>
>>>>>
>>>>> 2014-02-17 20:18 GMT+01:00 Davide D'Alto :
>>>>>
>>>>> > Hi.
>>>>> > I've noticed that when I run the build of OGM the documentation is
>>>>> not
>>>>> > completly built.
>>>>> > The part releated to the single datastores is missing.
>>>>> >
>>>>> > It works on Jenkins.
>>>>> >
>>>>> > Does it happen only to me?
>>>>> > ___
>>>>> > 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] Hakergarten session for Devoxx France

[Davide D';Alto]

I've used the same label


On Mon, Mar 17, 2014 at 3:09 PM, Sanne Grinovero wrote:

> I've used the "hackergarten" label for Search.
> Essentially I've picked among the ones already tagged as "suited for
> new contributors" those which I think are doable in shortest time.
>
> https://hibernate.atlassian.net/issues/?jql=labels%20%3D%20hackergarten
>
> Davide could you use the same label for OGM?
>
> Sanne
>
> On 17 March 2014 14:29, Emmanuel Bernard  wrote:
> > I will be at Devoxx France to help on a Hackergarten session. This is
> > basically some time where people come to contribute to a project,
> > hopefully being the start of a long relationship :)
> >
> > I can mentor people around Hibernate Search and Hibernate OGM. Could you
> > tag some issues on JIRA as easily doable in 1 to 2 hours.
> >
> > Emmanuel
> > ___
> > 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] Move container integration test to a separate default test cycle

[Davide D';Alto]

> 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 without
using maven
and then run the maven build assuming that everything needed is already
downloaded and started.



On Tue, Mar 25, 2014 at 11:31 AM, Sanne Grinovero wrote:

> My vote goes to #1 as well for the short term.
>
> There also is a third option, which requires some more work but
> provides a very nice balance.
> A great deal of the slowness of this complex matrix execution can be
> addressed to the continuous startup and teardown of services like the
> various databases and the datastores.
>
> Considering that each of those services starts in less than a second,
> the problem is not the single startup but literally the compound
> effect of the complex matrix: if we started say MongoDB, and CouchDb,
> and all others, and all containers at the beginning of the suite, we
> could then run matrix tests in a very efficient way, I'd bet we could
> keep the full matrix *and* the testsuite under a single minute. The
> goal would be to reuse a single WildFly (or EAP) startup to test on
> each database; i.e. 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.
>
> For the OGM needs to test on EAP, I just dicussed with Davide (same
> office today), and since we'd be testing an old version of EAP
> (6.1.0.Alpha1 being the latest in public Maven repositories), our idea
> is that this is too old to be useful anyway. We'll set up a profile -
> disabled by default - which downloads and tests latest EAP to be used
> by the Jenkins instance running at Red Hat.
>
> Sanne
>
>
> On 25 March 2014 09:25, Emmanuel Bernard  wrote:
> > This is a follow up on
> >
> https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092
> >
> > We keep piling up new backends, new containers to test and new rules
> > checked at build time. A consequence is that it is becoming less and
> > less pleasant to work on OGM.
> >
> > You can see that n version of Naked+WF+EAP+... multiplied by m backends
> > simply will make this project horrendously slow to contribute to.
> > I imagine n = 3 or 4 and m = 10 in a medium term.
> >
> > I see two options that would keep us around for a while:
> >
> > 1. Make the container integration tests only run with a specific option
> >activated on the CI.
> > 2. Move the container integration tests outside in a different repo
> >altogether.
> >
> > I do prefer 1.
> >
> > Emmanuel
> > ___
> > 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] CI jobs hang (Gunnar Morling)

[Davide D';Alto]

I going to update Jenkins and the plugins to see if it solves this issue.

Are there any reasons I shouldn't do this?


On Tue, Apr 1, 2014 at 2:11 PM, Gunnar Morling  wrote:

> Hi Paolo,
>
> Thanks for your reply. The thing is that these jobs used to work until
> recently, so I'm wondering which change could be causing the problem. Maybe
> a recent update to Jenkins or one of the plug-ins?
>
> Unfortunately we don't have the config audit plug-in anymore which provides
> a history at least of changes to job configs. @Davide, I think I had
> installed it once but I guess it got lost when rebuilding the instance via
> Puppet? Any chance you could add this plug-in permanently?
>
> @Paolo: Would be very interested to learn more about the Docker stuff
> you're working on once you got something :)
>
> --Gunnar
>
>
>
>
>
> 2014-04-01 15:02 GMT+02:00 Paolo Antinori :
>
> > Hi Gunnar
> >
> > I am working on related activities on a replica of ci.hibernate.orgwhere
> > I
> > am playing with Docker and trying to see how well it could fit the the
> > project build needs.
> >
> > When running OGM build job on this replica server, I have noticed the
> same
> > problem.
> >
> > I think that the problem is related to Axis plugin, like you were
> pointing
> > out.
> >
> > I have also noticed this:
> >
> > http://ci.hibernate.org/job/hibernate-ogm-master/106/consoleText
> >
> > That is the link for the plain text version of the logs.
> >
> > Not sure if the message you find there:
> >
> > No such file:
> > /var/lib/jenkins/jobs/hibernate-ogm-master/builds/2014-04-01_07-01-01/log
> >
> > Is the blocking problem or just a side-effect of something else.
> >
> > I hope to be able to show soon a Docker based approach to possibly bypass
> > totally this kind of problems.
> >
> > paolo
> >
> >
> > On Tue, Apr 1, 2014 at 12:46 PM,  > >wrote:
> >
> > > Send hibernate-dev mailing list submissions to
> > > hibernate-dev@lists.jboss.org
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > or, via email, send a message with subject or body 'help' to
> > > hibernate-dev-requ...@lists.jboss.org
> > >
> > > You can reach the person managing the list at
> > > hibernate-dev-ow...@lists.jboss.org
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of hibernate-dev digest..."
> > >
> > > Today's Topics:
> > >
> > >1. [OGM] CI jobs hang (Gunnar Morling)
> > >2. Re: Session and carrying 3rd party state (Gunnar Morling)
> > >3. Re: Session and carrying 3rd party state (Gunnar Morling)
> > >
> > >
> > > -- Forwarded message --
> > > From: Gunnar Morling 
> > > To: "hibernate-dev@lists.jboss.org" 
> > > Cc:
> > > Date: Tue, 1 Apr 2014 09:20:28 +0200
> > > Subject: [hibernate-dev] [OGM] CI jobs hang
> > > Hi,
> > >
> > > For some reason, the CI jobs for OGM can't be executed (all jobs,
> master,
> > > java8, PR seem affected) . They hang forever in an initial state, i.e.
> > > there is no console output and also the sub-jobs are not dispatched
> > (these
> > > are matrix projects). Worse, they can't even be canceled (trying to do
> so
> > > has no effect), only a server restart helps.
> > >
> > > Have there been any recent changes to the job (or server) config which
> > may
> > > cause this? I found
> > https://issues.jenkins-ci.org/browse/JENKINS-9688which
> > > indicates, that the jobs may be waiting eternally for a resource which
> > they
> > > can't acquire (I don't see any resources requested in the job config,
> > but I
> > > vaguely remember something around JGroups channels).
> > >
> > > Does anyone know what's going on here?
> > >
> > > --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] GitHub repo for demo projects

[Davide D';Alto]

+1


On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer  wrote:

> +1 from me.  I have several to contribute as well from various ORM
> presentations.
>
> https://github.com/brmeyer/HibernateDemos
>
> - Original Message -
> From: "Gunnar Morling" 
> To: hibernate-dev@lists.jboss.org
> Sent: Monday, April 28, 2014 10:49:19 AM
> Subject: [hibernate-dev] GitHub repo for demo projects
>
> Hi,
>
> Together with Sanne I've been creating a demo app which shows some features
> of Hibernate OGM.
>
> Right now this lives under my personal account on GitHub, but IMO it'd make
> sense to move it somewhere under https://github.com/hibernate/ to make it
> more visible, encourage re-use and contributions by others etc.
>
> What do you think about creating a repo under the hibernate organization
> such as "hibernate-demos" which could host this and other demos for our
> projects in the future? Or would it even make more sense on a per-project
> base ("hibernate-ogm-demos" etc.)?
>
> --Gunnar
>
> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> ___
> 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] GSoC Introduction

[Davide D';Alto]

Welcome Kahlid!


On Fri, May 2, 2014 at 10:34 AM, Gunnar Morling wrote:

> 2014-05-02 11:30 GMT+02:00 Sanne Grinovero :
>
> > Hi Khalid,
> > that's great news, welcome!
> >
>
> Welcome again and looking forward to your contributions, Khalid; I'm very
> excited about this GSoC project becoming a reality!
>
> --Gunnar
>
>
>
> > Sanne
> >
> > On 2 May 2014 08:42, Khalid Alqinyah  wrote:
> > > Hi all,
> > >
> > > My name is Khalid Alqinyah.
> > >
> > > I'll be working on 'HV-825 Integration with Java 8' as part of Google
> > > Summer of Code 2014. I'll be mentored by Gunnar and Hardy.
> > >
> > > Looking forward to this project and working with the dev team.
> > >
> > > /Khalid
> > > ___
> > > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate OGM 4.1.0.Beta4 is out, with support for MongoDB CLI syntax and bidirectional relationships for Neo4j

[Davide D';Alto]

Hi,

I'm happy to announce a new release of Hibernate OGM.

The MongoDB backend now supports the MongoDB CLI syntax for native queries.
In Neo4j, we have solved a bug related to the way we store embedded
collections (OGM-549 ) and
we now create only one relationship for bidirectional associations. We have
also worked on the compatibility with WildFLy 8.1.

Check out the anonuncement for more details[1].
Davide
[1]
http://in.relation.to/Bloggers/HibernateOGM410Beta4IsOutWithSupportForMongoDBCLISyntaxAndBidirectionalRelationshipsForNeo4j
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate OGM 4.1 Beta 5 is out: JP-QL queries for Neo4j and more

[Davide D';Alto]

It's my pleasure to announce a new release of Hibernate OGM.

Hibernate OGM can now convert JP-QL queries into cypher queries when
working with Neo4j. We improved the JSON representation used for
associations in CouchDB and MongoDB making it more concise. We also worked
on several bug fixes and improvements under the hood.

Check out the anonuncement for more details[1].
Davide
[1]
http://in.relation.to/Bloggers/HibernateOGM410Beta5IsOutJPQLQueriesForNeo4jAndMore

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

[hibernate-dev] Embedded value not null when it includes an @ElementCollection

[Davide D';Alto]

Hi,
I've created a test for OGM where we store an @Embeddable containing a list
annotated with @ElementCollection [1]:

This is the embedded:

@Embeddable
public class PhoneNumber {

private String main;

@ElementCollection
private List alternatives;

...

}

In the test [2] I first save an entity with the embedded attribute set to
null and then I call a session.get(...) to obtain it. The embedded
attribute is not null as I was expecting.

The same this happend when I've tried it on ORM, is this the expected
behaviour?

Thanks,
Davide

[1]
https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java

[2]
https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Embedded value not null when it includes an @ElementCollection

[Davide D';Alto]

Hi,
I've created a test for OGM where we store an @Embeddable containing a list
annotated with @ElementCollection [1]:

This is the embedded:

@Embeddable
public class PhoneNumber {

private String main;

@ElementCollection
private List alternatives;

...

}

In the test [2] I first save an entity with the embedded attribute set to
null and then I call a session.get(...) to obtain it. The embedded
attribute is not null as I was expecting.

The same this happend when I've tried it on ORM, is this the expected
behaviour?

Thanks,
Davide

[1]
https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java

[2]
https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Embedded value not null when it includes an @ElementCollection

[Davide D';Alto]

Thanks,

Davide

On Thu, Sep 18, 2014 at 3:15 PM, Steve Ebersole  wrote:

> I have not played with case specifically, but it makes sense.  ORM tries
> hard to never return a null collection reference.
>
> On Wed, Sep 17, 2014 at 10:31 AM, Davide D'Alto 
> wrote:
>
>> Hi,
>> I've created a test for OGM where we store an @Embeddable containing a
>> list
>> annotated with @ElementCollection [1]:
>>
>> This is the embedded:
>>
>> @Embeddable
>> public class PhoneNumber {
>>
>> private String main;
>>
>> @ElementCollection
>> private List alternatives;
>>
>> ...
>>
>> }
>>
>> In the test [2] I first save an entity with the embedded attribute set to
>> null and then I call a session.get(...) to obtain it. The embedded
>> attribute is not null as I was expecting.
>>
>> The same this happend when I've tried it on ORM, is this the expected
>> behaviour?
>>
>> Thanks,
>> Davide
>>
>> [1]
>>
>> https://github.com/hibernate/hibernate-ogm/blob/8a8b29f660973cad4c340931c4dcf9536342721b/core/src/test/java/org/hibernate/ogm/backendtck/embeddable/PhoneNumber.java
>>
>> [2]
>>
>> https://github.com/hibernate/hibernate-ogm/commit/bfed4e2df06f18960502af24fea72d45c1002fe7#diff-024806c2656dbe23ae1a5526f3a6845fR195
>> ___
>> 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] Hibernate OGM 4.1.0.Beta8 is out: Optimistic locking and performance improvement

[Davide D';Alto]

We are getting closer to a final release and this version is mainly about
improving general performance and reducing the amount of round trips to the
datastore.

We also added optimistic locking support for datastores which provide
atomic find-and-update operations.

You can read more about it in the blog post:
http://in.relation.to/Bloggers/HibernateOGM410Beta8IsOutOptimisticLockingAndPerformanceImprovement

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

Re: [hibernate-dev] Maintenance on ci.hibernate.org

[Davide D';Alto]

On a related note,
I've also reinstalled couchdb since it stopped working for some reason.

I've also changed the maven version used for hibernate-ogm-master-jdk9 to
maven 3.2.3.
Maven 3.2.3 fixes some some bugs related to the profiles activation.

Davide


On Sun, Nov 30, 2014 at 10:22 PM, Sanne Grinovero 
wrote:

> All,
> we needed to do some unplanned maintenance on ci.hibernate.org.
>
> At some point it was clear that we needed do deploy some significant
> upgrades so while Davide fixed Apache HTTPD, I went ahead and updated
> all of Jenkins plugins as well.. which I usually avoid to not need
> checking all builds and integrations with external services, but this
> time all validations would be needed anyway.
>
> So:
>  - I'm sorry if you received some false notifications from it.
>  - If some builds are now broken, it might need some reconfiguration.
>  - same for plugins configurations: I'm unable to double-check all
> things you've all setup.
>
> Please let me know what isn't working anymore, or if you have a moment
> to volunteer looking yourself that would be great.
>
> # Reminder
> Anyone in the Hibernate organization on GitHub has configuration and
> write permissions on this server; if you know what you're doing feel
> free to take advantage of that but please always share a summary of
> what you did / plan to do.
>
> 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] Slot name for modules of Hibernate OGM

[Davide D';Alto]

+1
There is already a JIRA open to rename the module:
https://hibernate.atlassian.net/browse/OGM-698

We can update it with more details.

On Thu, Jan 8, 2015 at 10:21 PM, Sanne Grinovero 
wrote:

> I just noticed that the main module for Hibernate OGM has slot="ogm",
> while the various dialect extension modules use the "main" slot.
>
> My understanding is that "main" should be reserved for the version
> included in a specific application server version, so we'd better
> avoid it to make it possible to eventually include OGM in WildFly and
> still be able to differentiate versions.
>
> The "ogm" slot also doesn't make it possible to use multiple versions,
> which is ok now that there's a single release but won't be
> sustainable.
>
> Could we use the same label for all modules in a specific release, and
> encode version in it too?
> I propose using "ogm-{Major.Minor.Micro}".
>
> Using the ".Micro" postfix might seem overzealous as micro versions
> are supposed to be drop-in compatible but I'd rather be safe and be
> able to be explicit; we could in addition provide an alias like we do
> with Hibernate Search and Infinispan; this seems to be working quite
> well so far.
> Such an alias deploys a module which defines for say "ogm-4.1" should
> look for "ogm-4.1.1": then applications can generally refer to
> "ogm-4.1" and let the alias resolve it, or be more explicit if they
> like so.
>
> 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

[hibernate-dev] in.relation.to error when posting a new blog entry

[Davide D';Alto]

Hi,
I'm trying to create a new blog entry on in.relation.to
but an exception occurs about the violation of an integrity constraint.

Any idea on how to solve the issue?

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

Re: [hibernate-dev] in.relation.to error when posting a new blog entry

[Davide D';Alto]

I'm currently trying to fix it

On Sat, Feb 14, 2015 at 1:13 AM, Gail Badner  wrote:

> Good questions. I'll wait for a reply...
>
> - Original Message -
> > From: "Hardy Ferentschik" 
> > To: "Sanne Grinovero" 
> > Cc: "Gail Badner" , "Davide D'Alto" <
> dav...@hibernate.org>, "hibernate-dev"
> > 
> > Sent: Friday, February 13, 2015 1:53:21 AM
> > Subject: Re: [hibernate-dev] in.relation.to error when posting a new
> blog entry
> >
> > On Thu, Feb 12, 2015 at 06:57:55AM +, Sanne Grinovero wrote:
> > > I suspect it's a broken foreign key on MySQL, hopefully the error
> message
> > > will have some details? Some table maintenance should do the trick.
> >
> > Do you literally talk about the table maintenance commands like
> > REPAIR TABLE
> > (http://dev.mysql.com/doc/refman/5.1/en/table-maintenance-sql.html),
> > or do you have something else in mind?
> >
> > Is it not a bit dangerous to let the uninitiated work against the prod
> > database?
> > Is there at least a nightly or at least regular copy of the database
> which
> > can be
> > restored in case something goes wrong? And if so where is it and how do
> I get
> > hold
> > of it?
> >
> > --Hardy
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Sprint organization

[Davide D';Alto]

> Before that though, I need to finish the Validator blog? What is the
status on in.relation.to? Can one create blog entries again?

in.relation.to it stills not working and I'm not sure how to solve the
issue.

The content in the db seems correct and I think the problem is related to
some operations
it's trying to perform on the db. It seems it's trying to delete a comment
and it is failing.

I'm open to suggestion.


On Mon, Feb 23, 2015 at 9:40 AM, Hardy Ferentschik 
wrote:

> Hi,
>
> On Mon, Feb 23, 2015 at 09:15:26AM +0100, Gunnar Morling wrote:
>
> > I'm curious how the weekly release scheme is going to work out. In the
> last
> > two sprints we created none (although I thought we wanted to release HS?)
> > and one (HV, as planned) release. Planning for four releases now may be
> > over-stretching it a bit, esp. when splitting up powers as we do in the
> > first week. I would have planned for 4.1.2 and a 4.2 release.
>
> I agree. I was surprised to see 4 schedules releases for this sprint.
> I have a hard time seeing this as realistic and to a certain degree scary.
>
> > As you say, it's too many issues, we will not be able to do them all.
> > Personally, I like a realistic schedule more, IMO it gives you a better
> > sense of achievement if you actually managed to tackle what you had
> > planned.
>
> +1
>
> > Now we'll more likely get the feeling that we failed to do half of
> > the things planned (as we know that's expected, still I find it
> > sub-optimal).
>
> +1
>
> I started with compiling the OGM code base and now need to set it up
> in my IDE and read some docs. Once I am a bit more familiar with all I'll
> pick an issue from the list.
>
> Before that though, I need to finish the Validator blog? What is the status
> on in.relation.to? Can one create blog entries again?
>
> --Hardy
>
> P.S.: I know this might not go down so well, but depending on the state
> of in.relation.to we might have to consider to put some effort into the
> blog
> conversion.
>
>
>
>
> ___
> 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] Moving to Java 7

[Davide D';Alto]

+1

Let's move to java 7

On Mon, Feb 23, 2015 at 10:40 AM, Gunnar Morling 
wrote:

> Hi,
>
> So far Hibernate OGM has been usable quite well when running on Java 6. But
> as more and more of our dependencies require Java 7, the number of cases
> where 6 is sufficient, decreases.
>
> With two out of four backends (Infinispan and Neo4j) as well as HSEARCH
> requiring 7 by now, I think it's about time to move on and take advantage
> of 7 ourselves as well.
>
> Are there any objections?
>
> 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] [OGM] Sprint organization

[Davide D';Alto]

I like the idea of a separate module for shared tests, It makes sense for
our usecase.
I've never been a big fun of the OGM black magic.

Are there any reasons not to do it except that it will add a new module?
I'm not really concerned about having modules in the project if their
purpose is clear.


On Wed, Feb 25, 2015 at 10:30 AM, Hardy Ferentschik 
wrote:

> > > Wouldn't it make sense to have these backendtck tests defined in a
> > > dedicated
> > > module? When you mentioned it, I was literally searching for the tests
> you
> > > were
> > > referring to.
> > >
> >
> > Sorry, I guess I should have given you the package name.
> >
> > I kind of like the fact that one can execute the tests in core right
> away,
> > i.e. without any copying, or custom runner etc. Would there be any strong
> > advantage to having them in a separate module? If not I'd prefer to keep
> > the number of modules low.
>
> More transparency. If the module existed I could already just by name infer
> what it is about. This might also be helpful for potential dialect
> contributors
> who look for high level tests.
>
> It is also in the spirit of one module one artifact. Unless I actually
> check the
> POM and find the second execution of the jar plugin, I don't know that two
> artifacts
> are generated.
>
> A dedicated module means less surprises and less understanding needed to
> see how
> things get together.
>
> Also, having a dedicated module allows for adding an additional README
> which for
> example described the purpose of these tests, how they are executed and
> that they
> are used by each dialect.
>
> --Hardy
> ___
> 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] Datomic OGM implementation

[Davide D';Alto]

Hi Josiah,
thank you very much, that looks like great news.

Usually before changing the existing  modules we discuss the requirements
on this mailing list, on the JIRA or on the forum.

Sending a pull request with the description of the problem is probably the
fastest way to have feedback, just keep the amount of changes to a minimum
so that it's easier for the reviewer to understand what's going on.

Cheers,
Davide

On Sat, Apr 25, 2015 at 2:00 AM, Haswell, Josiah D 
wrote:

> Hi folks,
>
> How can I begin to submit a new grid dialect to the project?  I'm most of
> the way through implementing a dialect for Datomic,
> and am most of the way through the approval process to submit it back to
> the community.  I've had to make some (pretty minor) changes to
> Hibernate-ogm-core that I'd like feedback on, as well.  Do I just submit a
> pull request?
>
> Thanks!
>
> Josiah Haswell
> ___
> 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] Which versions of the application server should the Hibernate OGM modules support

[Davide D';Alto]

> # EAP versions
>
> We're also producing modules for JBoss EAP6, but AFAIR these need some
> ove and I'm not sure if it's worth the effort - it might not need to
> much work and I'm happy to look at it if you want to, but in case we
>fix it these should have proper integration tests [next]:

I think we already have integration tests in place, we are not running them
at the moment
because the module for eap needs some love.

There is a profile in the pom of  hibernate-ogm-integrationtest.
If you enable the profile the test are executed (mvn -Peap).

It would probabaly be easier to maintain update if we move the tests in
different modules,
the speed of the build can still be managed via profile.

I think the reason it wasn't executed by default was mainly because there
was some complexity when downloading EAP from the repository for new
contributors.
I'm not sure if this is still the case

> # Integration tests of these modules
> ...
> B) change approach and have the tests re-run for any build

This is the solution I prefer although it might slow down the build.
Is it possible for a new contributor to dowload EAP from a maven repository
or does it requires
a special repository and related permissions?

Davide




On Tue, May 5, 2015 at 12:04 PM, Sanne Grinovero 
wrote:

> Hello all,
> I actually have multiple questions on the subject.
>
> # Module name
>
> The Maven artifact id of the modules we're producing for WildFly 8 is
> aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
>
> I still think that's a good choice, as deploying modules is an
> operation which is strictly coupled to the application server version.
> I'm merly reminding this point as it suggests we *could* if - we want
> to - easily produce modules for multiple application server versions.
>
> # EAP versions
>
> We're also producing modules for JBoss EAP6, but AFAIR these need some
> love and I'm not sure if it's worth the effort - it might not need to
> much work and I'm happy to look at it if you want to, but in case we
> fix it these should have proper integration tests [next]:
>
> # Integration tests of these modules
>
> The current solution is that the integration tests are run with a
> profile selection: so we choose upfront in the build if we want to
> test the wildfly8 modules or the eap6 modules.
>
> Are we still happy with this setup? I don't see a CI job which
> verifies the EAP6 modules and I doubt you're all running the tests
> twice.
> Should we:
>  A) add the CI job to verify the other profiles (EAP6 and others as needed)
>  B) change approach and have the tests re-run for any build
>  C) remove the EAP6 modules
>
> My vote goes for B, even though it will make test runs take a bit
> longer. To improve speed we can do other things - to be discussed
> separately so I'd hope we don't give the execution speed too much
> weight for the above choice.
>
> # WildFly 8 vs WildFly 9
>
> At the last meeting we agreed to support WildFly 9. We didn't decide
> at what cost towards WF8 users: should we drop the WF8 modules?
> I think I'm ok with dropping the older modules, however since we have
> chosen for a module name which includes the version, it's pretty easy
> for us to keep the WF8 modules around for now, and it's equally easy
> to remove them from the project in future when we don't want to do
> that anymore.
>
> Documentation (user complexity) wise the instructions would be
> identical so it's not a big burden to explain - one would just need to
> pick the right set of modules.
>
> I would prefer to keep the WF8 modules around for a little bit, but
> only if we agree on an integration testing strategy which is able to
> cover all the modules we build.
>
> # JBoss Logger version
>
> As a reminder, there's an update for JBoss Logger which - if applied -
> will make it harder for OGM to work on WF8. Gunnar is making some
> interesting suggestions to work around this on OGM-803 but let's see
> first if
>  - we really want to keep WF8
>  - cant we not simply wait to update, I don't see why we should seel
> trouble by upgrading this component now.
>
> 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

[hibernate-dev] [Search] Projections of collection of elements with embeddable

[Davide D';Alto]

Hi,

while working on OGM-781 I noticed that there is a problem with Hibernate
Search when trying to get the projection of a property that represents a
collection of elements..

EntityInfo#getProjections()[0] will always return the first value of the
association.

For example, if I index the following entity:

@Indexed
public static class ExampleEntity {

@Field(store = Store.YES)
Integer someInteger;

...

@Field(store = Store.YES)
@IndexedEmbedded
List someCollection;
}

and than add a projection on  "someCollection"

EntityInfo.getProjection()[0] will only return the first result of the
collection instead of returning a List.

This seems a bug to me.
I've already created a local branch that should fix the behaviour in this
case.

It also makes me wonder, what should we do with a list of embeddables?

For example:

@Field(store = Store.YES)
@IndexedEmbedded
List nestedExamples

In this case,  would it make sense to project "someCollection.someInteger"?
And what would be the expected result calling EntityInfo.getProjection()[0]?

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

[hibernate-dev] Hibernate OGM 4.2 Final is out

[Davide D';Alto]

Hi,

after several months of hard work, I'm happy to announce the next final
release of Hibernate OGM: 4.2.

Compared to 4.1.Final, this version includes:

- API for retrieving all executed and failed datastore operations,
- preview for Apache Cassandra support,
- Fongo support,
- new built-in types for boolean mapping,
- Support for MongoDB 3 and MongoDB replica sets
- HQL support improvements and bug fixes,
- bug fixes related to the mapping of embedded properties,
- at least JDK 7 is required.

You can find all the details in the blog post [1].

Many thanks to all the people that helped us make this release possible.

Cheers,

Davide

[1] http://in.relation.to/Bloggers/HibernateOGM42FinalIsOut
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [WEBSITE] Jira workflow

[Davide D';Alto]

Hi,
it seems thath the worflow for WEBSITE on JIRA does not include the state
"PULL REQUEST SENT" (like in Search and OGM, for example)

I'd like to have it so that I can have a quick overview from JIRA of the
issues that are "almost" done.

Would it be ok to add it?

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

Re: [hibernate-dev] [WEBSITE] Jira workflow

[Davide D';Alto]

I've changed the workflow.

@hardy You seem to have the same permisison I have (I just gave a quick
look). Is there something in particular you cannot do?


On Fri, Jun 12, 2015 at 8:35 PM, Hardy Ferentschik 
wrote:

> Hi,
>
> > it seems thath the worflow for WEBSITE on JIRA does not include the state
> > "PULL REQUEST SENT" (like in Search and OGM, for example)
> >
> > I'd like to have it so that I can have a quick overview from JIRA of the
> > issues that are "almost" done.
> >
> > Would it be ok to add it?
>
> +1 from my side.
>
> While on it, you could check the team permissions. It seems I don't have
> the same
> permissions on WEBSITE as on the other projects.
>
> --Hardy
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] GridDialect facets

[Davide D';Alto]

>> I have been adding a facet to GridDialect and found it surprisingly hard:
>
> What is a facet in this context.

Facet are additional interfaces that can be used on a GridDialect to add
features to it, like support for optimistic locking, batching or native id
generation.

> non datastore dialect? Is it not one dialect per datastore?

Emmanuel is talking about some decorator classes the we use in different
scenarios. They will delegate the operations to the datastore dialect but
will execute some additional logic
before/after. For example, the GridDialectLogger will add some log before
delegating the operations to selected dialect.

> * I’m also concerned about facet discoverability, I don’t think it’s
trivial for a dialect implementor to get the list of facets easily, which
will tend to bring minimal dialects without the advanced features.

Right, we could create an empty interface to flag them.






On Fri, Jul 24, 2015 at 9:32 AM, Hardy Ferentschik 
wrote:

> On Fri, Jul 24, 2015 at 09:56:24AM +0200, Emmanuel Bernard wrote:
>
> > I have been adding a facet to GridDialect and found it surprisingly hard:
>
> What is a facet in this context. I've seen you guys using this term on IRC
> as well,
> but I am not sure what you mean with it in relation to a GridDialect.
>
> >  which non datastore dialects was supposed to implement the facet
>
> non datastore dialect? Is it not one dialect per datastore?
>
> Just trying to understand what you guys are actually talking about ;-)
>
> --Hardy
>
> ___
> 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] GridDialect facets

[Davide D';Alto]

>> Right, we could create an empty interface to flag them.

> They all extend GridDialect already. Is there any easier way for an
dialect provider to learn about all the facets than inspecting the type
hierarchy of GridDialect?

I guess the point is to distinguish between the main datastore dialect, the
decorators and the optional facets. You cannot do that looking only at the
hierarchy.



On Fri, Jul 24, 2015 at 2:34 PM, Hardy Ferentschik 
wrote:

> On Fri, Jul 24, 2015 at 11:01:43AM +0200, Gunnar Morling wrote:
> > > > I have been adding a facet to GridDialect and found it surprisingly
> hard:
> > >
> > > What is a facet in this context. I've seen you guys using this term on
> IRC
> > > as well,
> > > but I am not sure what you mean with it in relation to a GridDialect.
> > >
> >
> > It's our way to model different (optional) capabilities of data stores.
> >
> > The main contract is GridDialect which offers the basic functionality
> each
> > store needs to support (getTuple(), insertOrUpdateAssocation() and so
> on).
> > Then there are several sub-types of it (e.g. QueryableGridDialect,
> > OptimisticLockingAwareGridDialect etc.) which allow a dialect to expose
> > advanced (or more efficient) functionality. Depending on which
> capabilities
> > a store exposes that way, engine will make use of it.
>
> Got it, thanks.
>
> > >  which non datastore dialects was supposed to implement the facet
> > >
> > > non datastore dialect? Is it not one dialect per datastore?
> > >
> >
> > Davide's answer says it :)
>
> +1 Thanks both of you. Always helps to understand the lingo.
>
> --Hardy
>
> ___
> 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] Thoughts for the Infinispan / Hot Rod dialect

[Davide D';Alto]

> I think that in the case of Hot Rod clients we should not use
> AtomicMaps

Out of curiosity, what about the grouping API?
We asked the Infinispan team to add some methods to it because we might use
them
to implement the dialect over HotRod. These methods are still missing in
the HotRod protocol, though;
as far as I know.

> Would you agree on try basing the approach on a brand new dialect

I'm fine having a separate dialect.

> and on protobuf schema generation?

What kind of information do you need to generate the schema?
Is it something that you can do using the information we provide via the
interface SchemaDefiner (and BaseSchemaDefiner) at startup?

Cheers,
Davide



On Tue, Jul 28, 2015 at 3:07 PM, Sanne Grinovero 
wrote:

> Hi all,
> with Infinispan in embedded mode we used AtomicMaps and
> FineGrainedAtomicMaps as an alternative way to map attributes and
> relations.
>
> In particular the relations are interesting because in SQL world one
> would run a query on junction tables, and on Infinispan embedded
> queries would only be an option on Hibernate Search / Infinispan Query
> annotated attributes, and also the AtomicMaps allow us to only load
> the section of relevant data (like on a RDBMs).
> The difference between the two kinds of AtomicMaps is in the locking
> level, each similar to the same kind of locking we'd normally have.
>
> On Hot Rod, AtomicMaps are not available so we opened (a long time
> ago) a feature request to implement them for Hot Rod - at least Java
> clients. Still, we don't have transactions in this case either so the
> locking benefits are also unavailable.
>
> I think that in the case of Hot Rod clients we should not use
> AtomicMaps, but rather resort to a protobuf schema generation, and
> essentially use the more traditional "query on jointables" approach.
> Hot Rod nowadays supports queries, and they can be indexed or non
> indexed so we could enable indexing on the ad-hoc tables we build for
> relations mapping, have the user "opt in" for additional indexes, and
> still allow some level of querying for the fields which have not been
> indexed; of course w/o join operations.
>
> We can generate an appropriate schema and upload it to Hot Rod
> automatically; that sounds like a great usability improvement for all
> Java clients dealing with Infinispan/remote, as its schema ads quite
> some stuff to the learning curve.
> Still, this automatic generation is a new and challenging field; some
> notes:
>  - protobuf schemas are generational -> more effective if you can
> generate the new one based on the existing one
>  - there's a Java encoder by Adrian here:
> https://github.com/infinispan/protostream
>  - Typically one would need to assign a stable sequence id to each field
>  - previous points will likely want us to dump the output resource
> somewhere, maybe even persist on Infinispan?
>
> On a very different topic, we also typically require from a
> GridDialect implementor to provide sequence generation capability. I
> don't see a solution for that over Hot Rod, it doesn't currently have
> any safe incremental id, but when I asked today I was told that
> Infinispan 8 might have it; Tristan pointed out you can upload a
> script and have it run on the server, which in turn has access to the
> transactions API so this should be possible but doesn't look too easy.
>
> Finally, we'll need using the distributed remote iterator for
> GridDialect#forEachTuple.
>
> So my conclusion is that to support Hot Rod we'd be better off to make
> a completely different GridDialect than the one for Infinispan
> embedded, as I can hardly see some shared code.
>
> Would you agree on try basing the approach on a brand new dialect and
> on protobuf schema generation? In terms of features, we can implement
> them all except:
>  - transactions & locks
>  - join queries
>
> 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

[hibernate-dev] HSEARCH Java 8 Date Time

[Davide D';Alto]

Hi,
I started to work on the creation of the bridges for the classes in the
java.time package.

I was wondering if we want to convert the values to long using the existing
approach we have now for java.util.Date.

In Hibernate Search a java.util.Date is converted into a long that
represents the number of milliseconds since January 1, 1970, 00:00:00 GMT
using getTime().

The same value can be obtain from a java.time.LocaDate via:

long epochMilli = date.atStartOfDay( ZoneOffset.UTC
).toInstant().toEpochMilli();

LocalDate has a method that returns the same value expressed in number of
days:

long epochDay = date.toEpochDay();


I would use the second approach

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

Re: [hibernate-dev] HSEARCH Java 8 Date Time

[Davide D';Alto]

> wouldn't use NumericField(s) in this case, as they are more
> effective only with larger ranges, while MM and DD are very short;


I'm ok with that, it just that the @DateBridge annotation allows to choose
the encoding
and it would sound strange not to enable this annotation for this type.




On Wed, Aug 5, 2015 at 11:41 AM, Sanne Grinovero 
wrote:

> Our current implementation converts Date in the long "distance from
> epoch" to allow correct range-queries treating each Date as an instant
> in time - allowing a universal sorting strategy. But a LocalDate is
> not an instant-in-time.
>
> A LocalDate is intentionally oblivious of the timezone; as the javadoc
> states, it's useful for birthdays, i.e. symbolic occurrences and
> potentially legal matters which don't fit into a universal sorting
> model but rather with the local political scene - we would need the
> combo {LocalDate, ZoneId} provided to be able to allow sorting across
> different LocalDate - or simply assume that they are all referring to
> the same Zone.
>
> I think that if the user is using a LocalDate type, he's implicitly
> hinting that the timezone is not relevant for the practical use
> (possibly even wrong); the most faithful representation would be the
> string form in ISO standard format or to encode the day,month,year as
> independent fields? This last detail depends on how it would be more
> efficient to store & query; probably the String format MMDD would
> be the most efficient internal representation to allow also correct
> sorting.
>
> I wouldn't use NumericField(s) in this case, as they are more
> effective only with larger ranges, while MM and DD are very short; not
> sure if it's worth splitting the year as a NumericField either, as the
> values will likely be strongly clustered in the same range of "recent
> years" - although that might depend on the application but it doesn't
> seem worth the complexity, so I'd index & store as a String MMDD.
>
> -- Sanne
>
>
> On 5 August 2015 at 11:10, Gunnar Morling  wrote:
> > Hi,
> >
> > What's the motivation for using a different representation in that case?
> >
> > For the sake of consistency, I'd use milli seconds since 1970-01-01
> across
> > the board. Otherwise it'll be more difficult to compare fields created
> from
> > properties of different date types.
> >
> > --Gunnar
> >
> >
> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto :
> >
> >> Hi,
> >> I started to work on the creation of the bridges for the classes in the
> >> java.time package.
> >>
> >> I was wondering if we want to convert the values to long using the
> existing
> >> approach we have now for java.util.Date.
> >>
> >> In Hibernate Search a java.util.Date is converted into a long that
> >> represents the number of milliseconds since January 1, 1970, 00:00:00
> GMT
> >> using getTime().
> >>
> >> The same value can be obtain from a java.time.LocaDate via:
> >>
> >> long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> >> ).toInstant().toEpochMilli();
> >>
> >> LocalDate has a method that returns the same value expressed in number
> of
> >> days:
> >>
> >> long epochDay = date.toEpochDay();
> >>
> >>
> >> I would use the second approach
> >>
> >> Davide
> >> ___
> >> 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] HSEARCH Java 8 Date Time

[Davide D';Alto]

If a user select a resolution that does not make much sense we can log a
warning.

But I think this might make sense:

   @DateBridge(resolution=MONTH)
   LocalDate birthday;


On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto  wrote:

> > What would you do though in case of the following:
> >
> >   @DateBridge
> >LocalDate myDate;
> >
> > encoding() defaults to NUMERIC, so would you a) raise an error, or b)
> ignore encoding() for LocalDate and friends? Both seem not right to me. I
> think there is nothing wrong with using NUMERIC encoding per-se for these
> types. We may recommend STRING but if NUMERIC really is what a user wants I
> would let them do so.
>
> +1
>
> > What do you suggest we do if a user maps the following?
>
> >   @DateBridge(resolution=MILLISECOND)
> >   LocalDate birthday;
>
>
> Nothing really,
> I would just consider a LocalDate the same as a LocalDateTime with time
> 00:00:000 (UTC time zone)
>
> It is equivalent to:
> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling 
> wrote:
>
>>
>>
>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero :
>>
>>> Our current implementation converts Date in the long "distance from
>>> epoch" to allow correct range-queries treating each Date as an instant
>>> in time - allowing a universal sorting strategy. But a LocalDate is
>>> not an instant-in-time.
>>>
>>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>>> potentially legal matters which don't fit into a universal sorting
>>> model but rather with the local political scene - we would need the
>>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>>> different LocalDate - or simply assume that they are all referring to
>>> the same Zone.
>>>
>>
>> Right, I had the latter in mind and would use UTC for that purpose.
>>
>>>
>>> I think that if the user is using a LocalDate type, he's implicitly
>>> hinting that the timezone is not relevant for the practical use
>>> (possibly even wrong); the most faithful representation would be the
>>> string form in ISO standard format or to encode the day,month,year as
>>> independent fields? This last detail depends on how it would be more
>>> efficient to store & query; probably the String format MMDD would
>>> be the most efficient internal representation to allow also correct
>>> sorting.
>>>
>>> I wouldn't use NumericField(s) in this case, as they are more
>>> effective only with larger ranges, while MM and DD are very short; not
>>> sure if it's worth splitting the year as a NumericField either, as the
>>> values will likely be strongly clustered in the same range of "recent
>>> years" - although that might depend on the application but it doesn't
>>> seem worth the complexity, so I'd index & store as a String MMDD.
>>>
>>
>> Agreed that this makes most sense, given the "symbolic" nature of
>> LocalDate.
>>
>> What would you do though in case of the following:
>>
>> @DateBridge
>> LocalDate myDate;
>>
>> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
>> ignore encoding() for LocalDate and friends? Both seem not right to me. I
>> think there is nothing wrong with using NUMERIC encoding per-se for these
>> types. We may recommend STRING but if NUMERIC really is what a user wants I
>> would let them do so.
>>
>>>
>>> -- Sanne
>>>
>>>
>>> On 5 August 2015 at 11:10, Gunnar Morling  wrote:
>>> > Hi,
>>> >
>>> > What's the motivation for using a different representation in that
>>> case?
>>> >
>>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>>> across
>>> > the board. Otherwise it'll be more difficult to compare fields created
>>> from
>>> > properties of different date types.
>>> >
>>> > --Gunnar
>>> >
>>> >
>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto :
>>> >
>>> >> Hi,
>>> >> I started to work on the creation of the bridges for the classes in
>>> the
>>> >> java.time package.
>>> >

Re: [hibernate-dev] HSEARCH Java 8 Date Time

[Davide D';Alto]

> What would you do though in case of the following:
>
>   @DateBridge
>LocalDate myDate;
>
> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
ignore encoding() for LocalDate and friends? Both seem not right to me. I
think there is nothing wrong with using NUMERIC encoding per-se for these
types. We may recommend STRING but if NUMERIC really is what a user wants I
would let them do so.

+1

> What do you suggest we do if a user maps the following?

>   @DateBridge(resolution=MILLISECOND)
>   LocalDate birthday;


Nothing really,
I would just consider a LocalDate the same as a LocalDateTime with time
00:00:000 (UTC time zone)

It is equivalent to:
LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );










On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling  wrote:

>
>
> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero :
>
>> Our current implementation converts Date in the long "distance from
>> epoch" to allow correct range-queries treating each Date as an instant
>> in time - allowing a universal sorting strategy. But a LocalDate is
>> not an instant-in-time.
>>
>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
>> states, it's useful for birthdays, i.e. symbolic occurrences and
>> potentially legal matters which don't fit into a universal sorting
>> model but rather with the local political scene - we would need the
>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>> different LocalDate - or simply assume that they are all referring to
>> the same Zone.
>>
>
> Right, I had the latter in mind and would use UTC for that purpose.
>
>>
>> I think that if the user is using a LocalDate type, he's implicitly
>> hinting that the timezone is not relevant for the practical use
>> (possibly even wrong); the most faithful representation would be the
>> string form in ISO standard format or to encode the day,month,year as
>> independent fields? This last detail depends on how it would be more
>> efficient to store & query; probably the String format MMDD would
>> be the most efficient internal representation to allow also correct
>> sorting.
>>
>> I wouldn't use NumericField(s) in this case, as they are more
>> effective only with larger ranges, while MM and DD are very short; not
>> sure if it's worth splitting the year as a NumericField either, as the
>> values will likely be strongly clustered in the same range of "recent
>> years" - although that might depend on the application but it doesn't
>> seem worth the complexity, so I'd index & store as a String MMDD.
>>
>
> Agreed that this makes most sense, given the "symbolic" nature of
> LocalDate.
>
> What would you do though in case of the following:
>
> @DateBridge
> LocalDate myDate;
>
> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
> ignore encoding() for LocalDate and friends? Both seem not right to me. I
> think there is nothing wrong with using NUMERIC encoding per-se for these
> types. We may recommend STRING but if NUMERIC really is what a user wants I
> would let them do so.
>
>>
>> -- Sanne
>>
>>
>> On 5 August 2015 at 11:10, Gunnar Morling  wrote:
>> > Hi,
>> >
>> > What's the motivation for using a different representation in that case?
>> >
>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>> across
>> > the board. Otherwise it'll be more difficult to compare fields created
>> from
>> > properties of different date types.
>> >
>> > --Gunnar
>> >
>> >
>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto :
>> >
>> >> Hi,
>> >> I started to work on the creation of the bridges for the classes in the
>> >> java.time package.
>> >>
>> >> I was wondering if we want to convert the values to long using the
>> existing
>> >> approach we have now for java.util.Date.
>> >>
>> >> In Hibernate Search a java.util.Date is converted into a long that
>> >> represents the number of milliseconds since January 1, 1970, 00:00:00
>> GMT
>> >> using getTime().
>> >>
>> >> The same value can be obtain from a java.time.LocaDate via:
>> >>
>> >> long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> >> ).toInstant().toEpochMilli();
>> >>
>> >> LocalDate has a method that returns the same value expressed in number
>> of
>> >> days:
>> >>
>> >> long epochDay = date.toEpochDay();
>> >>
>> >>
>> >> I would use the second approach
>> >>
>> >> Davide
>> >> ___
>> >> 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] HSEARCH Java 8 Date Time

[Davide D';Alto]

> Proposal: use numeric but still - rather than taking the milliseconds
> from epoch, take the resulting number from MMDD ?

I don't think I understand what you mean with "the resulting number from
MMDD".
Wouldn't be similar to get the number of days from epoch?

But basically, you are saying that I can use different numeric encoding for
different types. Isn't it?
So, for example:

java.util.Date, java.util.Calendar  and java.time.Instant,
java.time.LocalDateTime will use number of miliseconds from epoch
java.time.LocalDate: number of days from epoch
java.time.LocalTime: number of nanos in a day

> Ok that works but why write all those zeros in the index, when you can
> just write the date. I realize storage is cheap, but still we need to
> be careful as the index size affects performance ;-)

I don't think we need to store the 0s.
If I know the type of the field I already know the the time is 0.
Am I missing something?


On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero  wrote:

> On 5 August 2015 at 16:27, Gunnar Morling  wrote:
> >> as I'd like us to consider not
> > applying DateBridge on the new types as it doesn't seem to add much
> > practical value.
> >
> > Ok, that may make sense for types such as LocalDate. But there are types
> in
> > the new API which - unlike LocalDate - do describe an exact instant on
> the
> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
> > sure to support both encodings, NUMERIC and STRING (similar to
> Date/Calendar
> > so far) and thus apply @DateBridge.
>
> +1
>
> > Question is whether/how to index/persist TZ information, for Calendar it
> > seems not been persisted in the index so far?
>
> It's encoding the Calendar's time as distance from epoch, which is a
> neutral encoding so you don't need the TZ.
>
> For the old style Date/Calendar types we always assumed the value was
> a point-in-time, unless explicitly opting in for an alternative
> encoding.
> For example for the "birthday use case" a reasonable setting would
> have been String encoding with resolution=DAY, although passing in a
> Date instance having the right value (as in right timezone) would have
> been user's responsibility.. we simply take the long it's storing and
> index that with the requested resolution.
>
> Sanne
>
> >
> >
> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero :
> >>
> >> Inline:
> >>
> >> On 5 August 2015 at 15:42, Davide D'Alto  wrote:
> >> > If a user select a resolution that does not make much sense we can
> log a
> >> > warning.
> >>
> >> +1 And update the javadoc to mention that some resolution values don't
> >> apply
> >>
> >> > But I think this might make sense:
> >> >
> >> >@DateBridge(resolution=MONTH)
> >> >LocalDate birthday;
> >>
> >> Ok but how often do you think that will be used?
> >> Sorry playing devil's advocate here, as I'd like us to consider not
> >> applying DateBridge on the new types as it doesn't seem to add much
> >> practical value.
> >>
> >> I agree it's worth a shot, but while going ahead keep in mind that
> >> maybe simplifying that is the more elegant solution.
> >>
> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto 
> >> > wrote:
> >> >
> >> >> > What would you do though in case of the following:
> >> >> >
> >> >> >   @DateBridge
> >> >> >LocalDate myDate;
> >> >> >
> >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or
> b)
> >> >> ignore encoding() for LocalDate and friends? Both seem not right to
> me.
> >> >> I
> >> >> think there is nothing wrong with using NUMERIC encoding per-se for
> >> >> these
> >> >> types. We may recommend STRING but if NUMERIC really is what a user
> >> >> wants I
> >> >> would let them do so.
> >>
> >> I'm all for letting the users have the last word, but this is one of
> >> those cases in which you don't know if they explicitly want that or
> >> simply went with the defaults.
> >>
> >> Not a big problem as of course the important thing of defaults is that
> >> "they work" but I'd really prefer the default to try be the most
> >> appropriate encoding, which is not numeric in this case.
> >>
> >> 

Re: [hibernate-dev] HSEARCH Java 8 Date Time

[Davide D';Alto]

e? But good for other more advanced needs.
>
> >
> > Even better though would be, if we would be able to support directly the
> use of date types in the from and to clauses.
> > It would be the responsibility of the DSL to round the specified types
> to the appropriate level based on the field's
> > configuration/metadata. Even in this scenario though a Search specific
> DateTools might be necessary for the cases
> > where the date specified in to/from needs to be rounded differently than
> the field itself.
>
> +1
>
> > Last but not least, the documentation needs to be updated. At the
> moment, the docs are silent about all the complexity
> > around dates. With the support of the new types, the docs needs to be
> more explicit and describe the subtleties at play.
>
> +1 created HSEARCH-1958
>
> Thanks,
> Sanne
>
>
> >
> > --Hardy
> >
> >
> > On Wed, Aug 05, 2015 at 05:40:16PM +0100, Sanne Grinovero wrote:
> >> On 5 August 2015 at 17:22, Davide D'Alto  wrote:
> >> >> Proposal: use numeric but still - rather than taking the milliseconds
> >> >> from epoch, take the resulting number from MMDD ?
> >> >
> >> > I don't think I understand what you mean with "the resulting number
> from
> >> > MMDD".
> >> > Wouldn't be similar to get the number of days from epoch?
> >>
> >> No because epoch is a specific moment *with a timezone*. If you take a
> >> calendar date "here", and take the moment in time which represents
> >> your beginning of the calendar date, the distance from epoch is not a
> >> whole number and you'd have to apply rounding which is timezone
> >> specific.
> >>
> >> By simply encoding the number in the above format, you'd encode today
> >> as the number "20150805".
> >> That's a whole number which avoids the timezone relativity and can be
> >> efficiently encoded in numeric form, and provides the expected sorting
> >> properties.
> >>
> >> >
> >> > But basically, you are saying that I can use different numeric
> encoding for
> >> > different types. Isn't it?
> >>
> >> Yes, you definitely need different encodings depending on the type and
> >> the used options.
> >>
> >> > So, for example:
> >> >
> >> > java.util.Date, java.util.Calendar  and java.time.Instant,
> >> > java.time.LocalDateTime will use number of miliseconds from epoch
> >> > java.time.LocalDate: number of days from epoch
> >>
> >> Except this one ^ I agree with the others.
> >>
> >> > java.time.LocalTime: number of nanos in a day
> >>
> >> Conceptually, yes.. but we don't have "nanoseconds" as an option of
> >> org.hibernate.search.annotations.Resolution. Should we add it?
> >> We would not be able to apply that Resolution on old fashioned
> >> Date/Calendar, so that would need a warning or even an exception when
> >> applied to old style value types.
> >>
> >> >> Ok that works but why write all those zeros in the index, when you
> can
> >> >> just write the date. I realize storage is cheap, but still we need to
> >> >> be careful as the index size affects performance ;-)
> >> >
> >> > I don't think we need to store the 0s.
> >> > If I know the type of the field I already know the the time is 0.
> >>
> >> Exactly
> >>
> >> > Am I missing something?
> >>
> >> I probably just misunderstood your proposal, since previously you
> >> mentioned: "I would just consider a LocalDate the same as a
> >> LocalDateTime with time 00:00:000 (UTC time zone)".
> >> If you have to write the days only you don't need to convert to a time
> first.
> >> This misunderstanding might be related with the fact that you were
> >> planning to encode as distance from epoch.. see my first comment on
> >> this same email.
> >> Since you don't want to look at distance from epoch for this case, the
> >> time component really is irrelevant and LocalDate has all the
> >> information you need.. simpler ;)
> >>
> >> Sanne
> >>
> >>
> >> >
> >> >
> >> > On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero 
> wrote:
> >> >
> >> >> On 5 August 2015 

Re: [hibernate-dev] HSEARCH Java 8 Date Time

[Davide D';Alto]

I've sent a pull request:
https://github.com/hibernate/hibernate-search/pull/887



Davide

On Mon, Aug 10, 2015 at 1:20 PM, Hardy Ferentschik 
wrote:

> On Mon, Aug 10, 2015 at 12:34:33PM +0100, Davide D'Alto wrote:
> > I'm not sure there is an easy way to convert Instant and DateTime to a
> > numeric value.
> > The problem is that the resolution for temporal types is nanoseconds, the
> > following datetime is valid:
> >
> > year: -999.999.999
> > month: 12
> > day: 31
> > hour: 23
> > minute: 59
> > second: 59
> > nanos: 999.999.999
> >
> > It gets more complicated when we need to store Offset or time zone.
>
> Why not just call Instant#toEpochMilli. I thought we agreed that for
> instant
> based time we stick to epoch time. There might be a loss in resolution, but
> I think this is fine in our case.
>
> --Hardy
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] CI Jobs and Byteman

[Davide D';Alto]

Hi all,
it seems that the Hibernate Search tests using Byteman are having some
conflicts with some ports used by the NoSql dbs we installed to test OGM.

For now I just set up the Search jobs  to work on ci-slave-4 where I have
stopped the dbs.

Tomorrow I will try to figure out the process that are causing the problem,
or I will script this solution.

Anyway, I'm open to suggestion.

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

Re: [hibernate-dev] CI Jobs and Byteman

[Davide D';Alto]

I've reconfigured all the jobs to works the same as before.
I've tried to replicate the issue with Byteman but it seems everything is
working well now.

Sanne, am I missing something about the way to run the build with search?


On Thu, Aug 20, 2015 at 9:44 AM, Sanne Grinovero 
wrote:

> +1 for a) as many jobs use Byteman, including ORM, and on many branches.
>
>
> On 20 August 2015 at 09:26, Hardy Ferentschik  wrote:
> > On Thu, Aug 20, 2015 at 08:48:36AM +0200, Gunnar Morling wrote:
> >> Wouldn't a better approach be to either a) run the NoSQL store in
> >> question on another port or b) configure Byteman to use another port?
> >
> > I guess both options work, but given that ports are anyways configurable
> in
> > the OGM build, a) might be the easier option
> >
> > --Hardy
> >
> > ___
> > 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] 2 CI slaves down

[Davide D';Alto]

Hi,
2 of the 4 slaves we use for CI are currently down.

Not sure what's the cause but I'm working on it.

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

Re: [hibernate-dev] Search/Validator: Deleting old release files on hibernate.org

[Davide D';Alto]

Can't we just move them into an archive folder?

On Tue, Aug 25, 2015 at 12:02 PM, Hardy Ferentschik 
wrote:

> Hi,
>
> On Tue, Aug 25, 2015 at 12:24:21PM +0200, Gunnar Morling wrote:
> > Can we delete all the non-displayed release files from
> > https://github.com/hibernate/hibernate.org/tree/staging/_data/projects
> > for Search and Validator?
>
> +1 I can take care of this. I noticed the time it takes as well.
> I kind of liked the idea of keeping the files and there are other
> things we could do to fix it, but I agree that deleting them is
> the simplest solution.
>
>
> --Hardy
>
>
> ___
> 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] HIbernate Shards contributors

[Davide D';Alto]

Hi,
on the forum someone is interested in updating the Hibernate Shards project:

https://forum.hibernate.org/viewtopic.php?f=9&t=1041314

In the website we ask to contact us if someone is interested to the project
but we don't provide an email address.


How should we reply to the post?

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

Re: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"

[Davide D';Alto]

Can't we keep some secrets tokens on master?
Or on a separate secret small machine?

This way we can transfer them from master during the creation of the slave.
Basically, I'm talking about improving the transfert-to-slave script.

> Davide extended this further with tags: see the readme to easily run
only the tasks related to a specific task (although we should tag all
tasks, not done yet).

I might now have explained that in the readme, but the Ansible
documentation is clear: http://docs.ansible.com/ansible/playbooks_tags.html

> FWIW, ECDSA is the future: get a better OS ;-)

+1 :)

Davide

On Wed, Aug 26, 2015 at 12:15 PM, Sanne Grinovero 
wrote:

> On 25 August 2015 at 14:15, Gunnar Morling  wrote:
> > Sanne,
> >
> > When running Ansible to update the CI slaves on OS X, I get the
> following error:
> >
> > TASK: [jenkins-slave | Ensure cimaster is a known host]
> ***
> > unknown key type ecdsa
> > fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
> > 54.174.65.136) returned 255
> >
> > Can we use another key type than "ecdsa"? Apparently the SSH coming
> > with OS X has no support for it (see [1]) and I'd prefer to use the
> > default version rather than having to install another one.
>
> That line though is just a trick to fetch the existing keys so I guess
> that to change the key type we need to figure out when & how these are
> generated.
> I just checked and it seems like we actually generate (and use) RSA
> keys now; maybe that line is just broken on all platforms (not just on
> OSX)?
> When making changes I only run the related portions of the Ansible
> script, so that might have been broken since a while w/o anyone
> noticing.
> Davide extended this further with tags: see the readme to easily run
> only the tasks related to a specific task (although we should tag all
> tasks, not done yet).
>
> I'm actually quite unhappy with that whole trick to get the generated
> nodes exchange the keys; it doesn't seem like "the Ansible way" as
> it's quite procedural, but I couldn't figure a better way other than
> pre-generate them (and lots of other people have that problem on SO so
> I'd hope it will improve).
> Would you prefer us to pre-generate those keys manually and add them
> to the list of secret tokens which we need to share among maintainers?
> I was trying to keep the list of keys we all need and the preparation
> steps minimal, but agree this one might not be worth the complexity.
>
> FWIW, ECDSA is the future: get a better OS ;-)
>
> Thanks,
> Sanne
>
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1]
> http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
> > ___
> > 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] Ansible set-up, error "unknown key type ecdsa"

[Davide D';Alto]

> That's what I proposed in the previous email, but there are tradeoffs
> such as having to maintain more secret keys somewhere. I'm not sure
> which approach is the lesser evil ;)

I prefer having the keys in one place of reference.
It's easier to remember to keep it up-to-date.







On Wed, Aug 26, 2015 at 12:38 PM, Sanne Grinovero 
wrote:

> On 26 August 2015 at 12:28, Davide D'Alto  wrote:
> > Can't we keep some secrets tokens on master?
> > Or on a separate secret small machine?
> >
> > This way we can transfer them from master during the creation of the
> slave.
> > Basically, I'm talking about improving the transfert-to-slave script.
>
> That's what I proposed in the previous email, but there are tradeoffs
> such as having to maintain more secret keys somewhere. I'm not sure
> which approach is the lesser evil ;)
>
> Sanne
>
>
> >
> >> Davide extended this further with tags: see the readme to easily run
> > only the tasks related to a specific task (although we should tag all
> > tasks, not done yet).
> >
> > I might now have explained that in the readme, but the Ansible
> documentation
> > is clear: http://docs.ansible.com/ansible/playbooks_tags.html
> >
> >> FWIW, ECDSA is the future: get a better OS ;-)
> >
> > +1 :)
> >
> > Davide
> >
> > On Wed, Aug 26, 2015 at 12:15 PM, Sanne Grinovero 
> > wrote:
> >>
> >> On 25 August 2015 at 14:15, Gunnar Morling 
> wrote:
> >> > Sanne,
> >> >
> >> > When running Ansible to update the CI slaves on OS X, I get the
> >> > following error:
> >> >
> >> > TASK: [jenkins-slave | Ensure cimaster is a known host]
> >> > ***
> >> > unknown key type ecdsa
> >> > fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
> >> > 54.174.65.136) returned 255
> >> >
> >> > Can we use another key type than "ecdsa"? Apparently the SSH coming
> >> > with OS X has no support for it (see [1]) and I'd prefer to use the
> >> > default version rather than having to install another one.
> >>
> >> That line though is just a trick to fetch the existing keys so I guess
> >> that to change the key type we need to figure out when & how these are
> >> generated.
> >> I just checked and it seems like we actually generate (and use) RSA
> >> keys now; maybe that line is just broken on all platforms (not just on
> >> OSX)?
> >> When making changes I only run the related portions of the Ansible
> >> script, so that might have been broken since a while w/o anyone
> >> noticing.
> >> Davide extended this further with tags: see the readme to easily run
> >> only the tasks related to a specific task (although we should tag all
> >> tasks, not done yet).
> >>
> >> I'm actually quite unhappy with that whole trick to get the generated
> >> nodes exchange the keys; it doesn't seem like "the Ansible way" as
> >> it's quite procedural, but I couldn't figure a better way other than
> >> pre-generate them (and lots of other people have that problem on SO so
> >> I'd hope it will improve).
> >> Would you prefer us to pre-generate those keys manually and add them
> >> to the list of secret tokens which we need to share among maintainers?
> >> I was trying to keep the list of keys we all need and the preparation
> >> steps minimal, but agree this one might not be worth the complexity.
> >>
> >> FWIW, ECDSA is the future: get a better OS ;-)
> >>
> >> Thanks,
> >> Sanne
> >>
> >> >
> >> > Thanks,
> >> >
> >> > --Gunnar
> >> >
> >> > [1]
> >> >
> http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
> >> > ___
> >> > 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] Query Parser Redesign

[Davide D';Alto]

+1

On Thu, Aug 27, 2015 at 10:09 AM, Sanne Grinovero 
wrote:

> On 26 August 2015 at 23:20, Steve Ebersole  wrote:
> > I'm ok with that.  Everyone else?
> >
> >
> > On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling 
> wrote:
> >>
> >> hibernate-query-parser?
>
> +1
>
> >>
> >> 2015-08-26 22:32 GMT+02:00 Steve Ebersole :
> >> > I think I'd like to rename this repo and the 2 modules.  I think its
> >> > easier
> >> > to call the overall repo hibernate-sqm.  And then within that rename
> the
> >> > 2
> >> > modules:
> >> > * hibernate-sqm -> hibernate-sqm-model
> >> > * hibernate-query-interpreter -> ?
> >> >
> >> > Still not sure what to call this "query->SQM" module.  Thoughts?
> >> >
> >> >
> >> > On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero 
> >> > wrote:
> >> >
> >> >> On 26 August 2015 at 18:27, Steve Ebersole 
> wrote:
> >> >> > Yes, but at this point lets make sure there is a Jira for any
> changes
> >> >> > we
> >> >> > are making.
> >> >> >
> >> >> > Also, I wanted to be specific that *no* clients of this code belong
> >> >> > in
> >> >> this
> >> >> > repo.  I know y'all did that with the hibernate-hql-parser repo.  I
> >> >> > just
> >> >> > want to be clear that that should *not* happen here.
> >> >>
> >> >> We had a short chat about this ^ on IRC; in summary I agree but we'll
> >> >> have to deal with the following difficulties.
> >> >>
> >> >> The obvious limitation of that is that each other project
> implementing
> >> >> a tree walker will need to (potentially) adjust on internal tree
> >> >> changes, but since that's obviously needed only when you upgrade the
> >> >> parser version you want to use, the problem is deferred; assuming we
> >> >> don't actually start all implementing such walkers until the tree is
> >> >> relatively stable, that should be a fair enough limitation to not
> push
> >> >> the burden of maintenance on the main parser maintainers, but keep
> the
> >> >> effort as an opt-in choice for those wishing to upgrade.
> >> >>
> >> >> The other little negative of that approach is that the current
> backend
> >> >> which generates Lucene queries depends on Hibernate Search and is
> >> >> consumed by both Hibernate OGM and by Infinispan, so having each
> >> >> "consuming project" host the tree walker would either prevent OGM and
> >> >> Infinispan to share the effort, or that would need an additional
> >> >> separate repository, or we could host it within Hibernate Search as
> >> >> some kind of parasite module (I'd rather not, for the same
> maintenance
> >> >> reason).
> >> >>
> >> >> We also wondered if the new parser should eventually be incorporated
> >> >> within the Hibernate ORM repository. In terms of dependencies it
> would
> >> >> not depend on hibernate-core so this would have no impact on other
> >> >> consumers, other than coupling the release cycle to ORM.
> >> >> Maybe this is premature to discuss as we certainly don't want it in
> >> >> there at least until ORM actually uses it, but I think that for end
> >> >> users it would be helpful to not have another dependency version to
> >> >> align..
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >>
> >> >>
> >> >> >
> >> >> > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <
> st...@hibernate.org>
> >> >> wrote:
> >> >> >
> >> >> >> Yes
> >> >> >>
> >> >> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <
> gun...@hibernate.org>
> >> >> wrote:
> >> >> >>
> >> >> >>> +1 for the new repo. Just forked it and am looking into the
> amazing
> >> >> >>> things you guys built recently :)
> >> >> >>>
> >> >> >>> Can I push simple stuff to that repo right away (e.g. adding the
> >> >> >>> Eclipse plug-in to build.gradle)?
> >> >> >>>
> >> >> >>> Cheers,
> >> >> >>>
> >> >> >>> --Gunnar
> >> >> >>>
> >> >> >>>
> >> >> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole :
> >> >> >>> > I also created Jira project ->
> >> >> >>> https://hibernate.atlassian.net/projects/SQM
> >> >> >>> >
> >> >> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole
> >> >> >>> > 
> >> >> >>> wrote:
> >> >> >>> >
> >> >> >>> >> I am starting that work here ->
> >> >> >>> >> https://github.com/hibernate/hibernate-semantic-query
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <
> >> >> and...@hibernate.org>
> >> >> >>> >> wrote:
> >> >> >>> >>
> >> >> >>> >>> no objections
> >> >> >>> >>>
> >> >> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole
> >> >> >>> >>> 
> >> >> >>> wrote:
> >> >> >>> >>>
> >> >> >>>  Anyone want to propose an alternative approach to what I
> have
> >> >> >>> working in
> >> >> >>>  my Antlr 4 PoC?
> >> >> >>> 
> >> >> >>>  If not, I think we should move that work to a GitHub
> Hibernate
> >> >> >>>  org
> >> >> >>> repo
> >> >> >>>  and start tracking work and Jiras there.  Objections?
> >> >> >>> 
> >> >> >>>  Also its no longer *just* HQL, we also plan to support JPA
> >> >> criteria
> >> >> >>>  queries here, interpreting them into semantic query models.
> 

[hibernate-dev] Hibernate Search 5.5 Final is out: Lucene 5

[Davide D';Alto]

*I’m happy to announce the latest final release of Hibernate
Search:Hibernate Search 5.5 Final.Here an overview of what Hibernate Search
5.5 brings to the table:- upgrade to Lucene 5- sortable fields- built-in
bridges for JDK 8 Java Time classes- encoding null tokens for numeric
fieldsYou can find more details on the blog
post:http://in.relation.to/2015/09/15/HS-5/
Cheers,Davide*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-9807 - @Id as @Formula

[Davide D';Alto]

What's the use case? A user that doesn't want to store the @Id but want it
to be available when loading the entity?

Davide

On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole  wrote:

> Votes on supporting this?
>
> https://hibernate.atlassian.net/browse/HHH-9807
> ___
> 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] HHH-9807 - @Id as @Formula

[Davide D';Alto]

> however it probably is a good idea to give a better indication tat this
is not supported aside from some deeply nested NPE .

+1

On Wed, Oct 7, 2015 at 2:31 PM, Steve Ebersole  wrote:

> I personally don't really see much of a justification for supporting
> this.  If no one else can help me see the justification, I will just reject
> the feature request; however it probably is a good idea to give a better
> indication tat this is not supported aside from some deeply nested NPE .
>
> On Wed, Oct 7, 2015 at 5:51 AM andrea boriero  wrote:
>
>> I don't figure out the use cases for @Formula on @Id as well
>>
>> On 7 October 2015 at 10:21, Davide D'Alto  wrote:
>>
>> > What's the use case? A user that doesn't want to store the @Id but want
>> it
>> > to be available when loading the entity?
>> >
>> > Davide
>> >
>> > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole 
>> > wrote:
>> >
>> > > Votes on supporting this?
>> > >
>> > > https://hibernate.atlassian.net/browse/HHH-9807
>> > > ___
>> > > 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
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SQM - alias registry

[Davide D';Alto]

> Here the aliases `o` don't ever infringe on each other.  So imo we should
allow that.

Sounds good

> Here the aliases `c` do infringe.  In the subquery, we don't really know
> which reference the `c` alias should resolve to.  We *could* here assuming
> that the subquery is uncorrelated.  Bu without this rule we really would
> not know that the subquery is correlated

Out of curiosity, Couldn't for this case assume that the second alias
overrides the first.
This might cause some hard to spot errors, though.

On Wed, Oct 7, 2015 at 3:00 PM, Steve Ebersole  wrote:

> At the moment the alias registry is global for the whole query.  I propose
> that we should scope this by "query spec" (combined with parent).  The
> reason being that reusing the same alias in unrelated subqueries is
> perfectly fine.
>
> select ...
> from Customer c
> where c.id in (
> select o.customer.id
> from Order o
> ...
> )
> or c.id in (
> select c1.id
> from Outstanding o
> ...
> )
>
> Here the aliases `o` don't ever infringe on each other.  So imo we should
> allow that.
>
> The piece about checking the parent is for a case like:
> select ...
> from Customer c
> where c.id in (
> select c.id
> from Order o
> join o.customer c
> ...
> )
>
> Here the aliases `c` do infringe.  In the subquery, we don't really know
> which reference the `c` alias should resolve to.  We *could* here assuming
> that the subquery is uncorrelated.  Bu without this rule we really would
> not know that the subquery is correlated.  Hopefully that makes sense, what
> I am getting at.
>
> WDYT?
> ___
> 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] Framework built on top of Hibernate: BabyFish

[Davide D';Alto]

Hi all,

I just want to mention that
a user on the Hibernate forum created a  framework on top of Hibernate:

https://forum.hibernate.org/viewtopic.php?f=1&t=1042072
https://github.com/babyfish-ct/babyfish

The main concept is around the use of an ObjectModel that replaces the
proxies and contains all the metadata to access the entities.

Here an example on how to define an object model in Java:
https://github.com/babyfish-ct/babyfish/blob/master/demo/babyfishdemo-om4java/src/main/java/org/babyfishdemo/om4java/fc/Employee.java

In JPA, the object model is generated during compile time and can be
accessed using:

private JPAObjectModelMetadata employeeOMM = JPAMetadatas.of(Company.class);

The ObjectModel provides a fluent API to get lazy associations,
disable/enable update on properties  and so on.

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

Re: [hibernate-dev] Framework built on top of Hibernate: BabyFish

[Davide D';Alto]

> BTW, the forum link was wrong.  I think you meant:
https://forum.hibernate.org/viewtopic.php?f=1&t=1042042

RIght, sorry.

On Thu, Oct 22, 2015 at 2:22 PM, Steve Ebersole  wrote:

> BTW, the forum link was wrong.  I think you meant:
> https://forum.hibernate.org/viewtopic.php?f=1&t=1042042
>
>
>
> On Thu, Oct 22, 2015 at 7:38 AM Davide D'Alto 
> wrote:
>
>> Hi all,
>>
>> I just want to mention that
>> a user on the Hibernate forum created a  framework on top of Hibernate:
>>
>> https://forum.hibernate.org/viewtopic.php?f=1&t=1042072
>> https://github.com/babyfish-ct/babyfish
>>
>> The main concept is around the use of an ObjectModel that replaces the
>> proxies and contains all the metadata to access the entities.
>>
>> Here an example on how to define an object model in Java:
>>
>> https://github.com/babyfish-ct/babyfish/blob/master/demo/babyfishdemo-om4java/src/main/java/org/babyfishdemo/om4java/fc/Employee.java
>>
>> In JPA, the object model is generated during compile time and can be
>> accessed using:
>>
>> private JPAObjectModelMetadata employeeOMM =
>> JPAMetadatas.of(Company.class);
>>
>> The ObjectModel provides a fluent API to get lazy associations,
>> disable/enable update on properties  and so on.
>>
>> Cheers,
>> Davide
>> ___
>> 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] recovering Neo4j transactions via their REST API...

[Davide D';Alto]

Hi Gytis,

I've sent a pull request for Neo4j remote some time ago:
https://github.com/hibernate/hibernate-ogm/pull/596

This is an initial prototype and it still requires some work.

That said, I think you will be able to obtain the transaction id via the
TransactionCoordinator:

TransactionDriver driver =
transactionCoordinator.getTransactionDriverControl();
Neo4jTransactionDriver neo4jDriver = (Neo4jTransactionDriver) driver;
Long transactionId = driver.getTransactionId();

As Emmanuel said, this might change in the future though, and it depends
what you need.

Cheers,
Davide

On Thu, Dec 3, 2015 at 7:40 PM, Emmanuel Bernard 
wrote:

> Hey Gytis,
>
> Davide is the right person to talk to. We were discussing this very
> subject during our face to face meeting and a few things will change. So
> now is a good time to feed your needs.
>
> Emmanuel
>
> > On 30 nov. 2015, at 16:23, Scott Marlow  wrote:
> >
> > Hi Gytis,
> >
> > Excellent to hear that you are looking at Neo4j.  I'm not sure, Emmanuel
> would be the better person to ask.
> >
> > Scott
> >
> >> On 11/26/2015 12:23 PM, HipChat wrote:
> >> Gytis Trikleris
> >> <
> https://www.hipchat.com/people/show/2470601?utm_medium=email&utm_source=oto_message_notification
> >
> >> just sent you a 1-1 message but you're offline:
> >>
> >> Gytis Trikleris
> >> Hey Scott! I am playing around with Neo4j as a result of your email for
> >> Tom last month. The one about recovering Neo4j transactions via their
> >> REST API.
> >> I'm checking whether it's doable, so would like to do a prototype for
> >> it. Do you know, if there is already a way to get Neo4j transaction id
> >> in OGM?
> >> 12:23 PM
> >> zdMpSzlniIzd770
> >>
> >>
> >>
>
> ___
> 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] The (new) remote Hot-Rod based Infinispan GridDialect

[Davide D';Alto]

I would use:
hibernate-ogm-infinispan-hotrod

For Neo4j we have a similart problem
at the moment the directory is hibernate-ogm-neo4j and the short name is
'neo4j_embedded'
Whatever we choose I guess we should be consistent:


I guess haivng
- hibernate-ogm-infinispan/embedded
- hibernate-ogm-infinispan/hotrod

On Mon, Dec 14, 2015 at 5:57 PM, Sanne Grinovero 
wrote:

> Hello all,
>while creating the basic scaffolding for the new GridDialect, I
> called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> is rather long, but descriptive.
>
> Q1: any better name?
>
>
>The current one which we have working on Infinispan "embedded mode"
> is named "hibernate-ogm-infinispan".
>
> Q2: do we need to rename the existing one? If not, what to we call it
> in our documentation to disambiguate?
>
>
> 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] [OGM] The (new) remote Hot-Rod based Infinispan GridDialect

[Davide D';Alto]

Sorry for the previous email, I've sent it too soon pressing some strange
keywords combination.

> We should stick to one pattern, and having one module seems easier on
> the user to me. So unless you see a strong advantage for two modules
> I'd say let's use one.

One general disadvantage I can see is that you add in the classpath
dependencies that you don't need (maybe).

> I would not have "hotrod" in the name, this is a technicality I'd
> prefer to not expose at this level. Rather "remote" vs. "embedded"

Are there other backends that could be associated with infinispan? Maybe a
different remote protocol?

> Regarding the provider names, "infinispan" and "infinspan-remote" seem
> good. If you think remote will be more common eventually, we may
> rename the current one and have "infinispan-embedded" and
> "infinispan". Requires a change to existing users, but it seems
> acceptable to do in 5.

I think that in general, remote dbs are more common. I would prefer
"infinispan-embedded" and "infinispan".

I guess based on what we decide we should also adapt the names and the
modules for Neo4j to be consistent.


On Mon, Dec 14, 2015 at 6:09 PM, Gunnar Morling 
wrote:

> Does it have to be a separate module to begin with?
>
> For MongoDB - which contains two datastore providers (MongoDB, Fongo)
> and Redis - which also will have two different dialects as per Mark's
> pending PR - it's one module.
>
> We should stick to one pattern, and having one module seems easier on
> the user to me. So unless you see a strong advantage for two modules
> I'd say let's use one.
>
> Regarding the provider names, "infinispan" and "infinspan-remote" seem
> good. If you think remote will be more common eventually, we may
> rename the current one and have "infinispan-embedded" and
> "infinispan". Requires a change to existing users, but it seems
> acceptable to do in 5.
>
> I would not have "hotrod" in the name, this is a technicality I'd
> prefer to not expose at this level. Rather "remote" vs. "embedded"
> which will be stable also if specific protocols change.
>
> --Gunnar
>
>
> 2015-12-14 18:57 GMT+01:00 Sanne Grinovero :
> > Hello all,
> >while creating the basic scaffolding for the new GridDialect, I
> > called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> > is rather long, but descriptive.
> >
> > Q1: any better name?
> >
> >
> >The current one which we have working on Infinispan "embedded mode"
> > is named "hibernate-ogm-infinispan".
> >
> > Q2: do we need to rename the existing one? If not, what to we call it
> > in our documentation to disambiguate?
> >
> >
> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [CI] MariDB size on jenkins slaves

[Davide D';Alto]

Hi,
the  file ibdata1 created by MariaDB has reached the size of 1G.
This happens because when deleting the tables the size of the db does not
decrease.

There are some possible solutions I can try, but I need to change the
configuration of the db and probably upgrade it.

Would that be ok?

I've also created a JIRA for this:
https://hibernate.atlassian.net/browse/WEBSITE-418

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

Re: [hibernate-dev] [CI] MariDB size on jenkins slaves

[Davide D';Alto]

It seems that the latest version of MariaDB has a feature that simplify the
process.

I'll try

On Tue, Dec 15, 2015 at 10:42 AM, Sanne Grinovero 
wrote:

> On 15 December 2015 at 10:23, Davide D'Alto  wrote:
> > Hi,
> > the  file ibdata1 created by MariaDB has reached the size of 1G.
> > This happens because when deleting the tables the size of the db does not
> > decrease.
> >
> > There are some possible solutions I can try, but I need to change the
> > configuration of the db and probably upgrade it.
> >
> > Would that be ok?
>
> Sure. Upgrading is fine too, but just configuration changes should be
> enough.
> As far as I remember MariaDB is unable to shrink its data tables, so
> if you reconfigure it after this size was already allocated it won't
> reduce the space; you might have to stop it, delete the data tables
> manually, and have it rebuild them.
>
> >
> > I've also created a JIRA for this:
> > https://hibernate.atlassian.net/browse/WEBSITE-418
> >
> > Cheers,
> > Davide
> > ___
> > 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

[hibernate-dev] [OGM] Hibernate OGM 5.0.0.Beta1 is out: Cassandra 2.2, @Lob mapping and @PostLoad support

[Davide D';Alto]

3 days from Christmas we decided to release Hibernate OGM as a present.

The major news in this release are:
- mapping support for Cassandra 2.2 new data types
- proper handling of the @Lob annotation
- post-load event support using @PostLoad annotation
- Infinispan 8
- Hibernate Search 5.5

You can find all the details about this release and what's coming next in
the blog post [1].

Many thanks to all the people that helped us make this release possible.

Cheers,

Davide

[1] http://in.relation.to/2015/12/21/hibernate-ogm-5-beta1-released/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] staging Blog site

[Davide D';Alto]

The hibernate.org job is working now.
I probably changed the label to slave4 when doing some maintenance work and
forgot to put it back to OS1.






On Thu, Jan 14, 2016 at 9:31 AM, Gunnar Morling 
wrote:

> > I thought those must be in-sync, like in a typical QA and production
> > environment where you push changes from develop -> qa -> production
>
> Staging can differ from production (usually be ahead) for previewing
> changes. Then "releasing" is just a fast-forward merge from staging to
> production. We don't enforce any specific workflow, though (like only
> merges from staging are legit to production or so).
>
> Personally, when using staging, I always try to leave it set to (or
> fast-forwardable to) production when I am done with a given authoring
> job. So the next guy coming after me doesn't have to care about any
> non-published commits on staging.
>
>
> 2016-01-14 10:21 GMT+01:00 Vlad Mihalcea :
> > Hi,
> >
> > Thanks for the clarifications. I thought that forced push is disabled,
> but
> > that might be true for the ORM, OGM, etc projects only.
> > I was also using a separate branch for every post, but I was branching
> from
> > staging because that was the default branch I got when forking the repo.
> >
> > I thought those must be in-sync, like in a typical QA and production
> > environment where you push changes from develop -> qa -> production
> > I'm now writing a new post and push it to both staging and production
> when
> > I'm done.
> >
> > Vlad
> >
> > On Thu, Jan 14, 2016 at 10:56 AM, Hardy Ferentschik  >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
> >> > I see that the production and the staging are out of sync now and
> trying
> >> > to
> >> > merge the upstream production leads to a merge commit.
> >> >
> >> > How do we normally handle the cases when the production branch history
> >> > diverges from staging?
> >>
> >> You force push production to staging. There is no strong requirement for
> >> staging being
> >> in sync with production. Staging is also there to test changes in the
> >> sites L&F or HTML
> >> fixes. It is quite common that staging and production are out of sync.
> >>
> >> For that reason it is important that when you want to blog you base your
> >> work on top of
> >> production and not staging. Staging is just a convenient place to try
> >> changes to the site.
> >> A forced push is perfectly ok.
> >>
> >> Personally I always pull from production and create "blog" branches from
> >> this branch.
> >> Then when I want to preview the changes life, I do a forced push to the
> >> staging branch.
> >> If I am happy with the result I push to production.
> >>
> >> --Hardy
> >>
> >
> ___
> 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] Activate URL links on blog

[Davide D';Alto]

+1

If they get abused we can always revert to the current state

On Thu, Jan 14, 2016 at 1:17 PM, Sanne Grinovero 
wrote:

> +1
>
>
> On Thu, 14 Jan 2016 11:18 Vlad Mihalcea  wrote:
>
> > Hi,
> >
> > Since we are now moderating the forum and disallow new users from
> posting,
> > we can activate links on the forum to increase user experience.
> > What do you think?
> >
> > Vlad
> > ___
> > 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] staging Blog site

[Davide D';Alto]

The staging.hibernate.org should now work again,
It was a problem of permissions, the owner of the folder with the site
changed (not sure why) and the rsync script wasn't able to update it.

Davide

On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea 
wrote:

> Thanks. The two branches are now in-sync.
>
> Vlad
>
> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik 
> wrote:
>
> > Hi,
> >
> > > Do we have to rewrite the staging history to match production and force
> > > push it?
> >
> > If you want staging to look like production, just push the production
> > branch onto staging.
> >
> > $ git push -f origin production:staging
> >
> > --Hardy
> >
> >
> ___
> 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] staging Blog site

[Davide D';Alto]

By the way, is there a way to recognize the staging website from the
production one?

If not we should probably add a timestamp somewhere and maybe a watermark
on some images.


On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto 
wrote:

> The staging.hibernate.org should now work again,
> It was a problem of permissions, the owner of the folder with the site
> changed (not sure why) and the rsync script wasn't able to update it.
>
> Davide
>
> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea 
> wrote:
>
>> Thanks. The two branches are now in-sync.
>>
>> Vlad
>>
>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik 
>> wrote:
>>
>> > Hi,
>> >
>> > > Do we have to rewrite the staging history to match production and
>> force
>> > > push it?
>> >
>> > If you want staging to look like production, just push the production
>> > branch onto staging.
>> >
>> > $ git push -f origin production:staging
>> >
>> > --Hardy
>> >
>> >
>> ___
>> 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] staging Blog site

[Davide D';Alto]

> you looking for something else than the different URLs?

Yes, something different than the URL.


On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling 
wrote:

> WDYM by "recognize the staging website from the production one?" Are
> you looking for something else than the different URLs?
>
>
> 2016-01-14 17:53 GMT+01:00 Davide D'Alto :
> > By the way, is there a way to recognize the staging website from the
> > production one?
> >
> > If not we should probably add a timestamp somewhere and maybe a watermark
> > on some images.
> >
> >
> > On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto 
> > wrote:
> >
> >> The staging.hibernate.org should now work again,
> >> It was a problem of permissions, the owner of the folder with the site
> >> changed (not sure why) and the rsync script wasn't able to update it.
> >>
> >> Davide
> >>
> >> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea  >
> >> wrote:
> >>
> >>> Thanks. The two branches are now in-sync.
> >>>
> >>> Vlad
> >>>
> >>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik <
> ha...@hibernate.org>
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > > Do we have to rewrite the staging history to match production and
> >>> force
> >>> > > push it?
> >>> >
> >>> > If you want staging to look like production, just push the production
> >>> > branch onto staging.
> >>> >
> >>> > $ git push -f origin production:staging
> >>> >
> >>> > --Hardy
> >>> >
> >>> >
> >>> ___
> >>> 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] staging Blog site

[Davide D';Alto]

> Ok, what for?

Right, not so useful in the end.

The idea is to make
make sure that one is publishing the right branch/rake[profile] in the
right url when the site is generated.


On Thu, Jan 14, 2016 at 5:47 PM, Gunnar Morling 
wrote:

> Ok, what for?
>
> 2016-01-14 18:45 GMT+01:00 Davide D'Alto :
> >> you looking for something else than the different URLs?
> >
> > Yes, something different than the URL.
> >
> >
> > On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling 
> > wrote:
> >>
> >> WDYM by "recognize the staging website from the production one?" Are
> >> you looking for something else than the different URLs?
> >>
> >>
> >> 2016-01-14 17:53 GMT+01:00 Davide D'Alto :
> >> > By the way, is there a way to recognize the staging website from the
> >> > production one?
> >> >
> >> > If not we should probably add a timestamp somewhere and maybe a
> >> > watermark
> >> > on some images.
> >> >
> >> >
> >> > On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto  >
> >> > wrote:
> >> >
> >> >> The staging.hibernate.org should now work again,
> >> >> It was a problem of permissions, the owner of the folder with the
> site
> >> >> changed (not sure why) and the rsync script wasn't able to update it.
> >> >>
> >> >> Davide
> >> >>
> >> >> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea
> >> >> 
> >> >> wrote:
> >> >>
> >> >>> Thanks. The two branches are now in-sync.
> >> >>>
> >> >>> Vlad
> >> >>>
> >> >>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik
> >> >>> 
> >> >>> wrote:
> >> >>>
> >> >>> > Hi,
> >> >>> >
> >> >>> > > Do we have to rewrite the staging history to match production
> and
> >> >>> force
> >> >>> > > push it?
> >> >>> >
> >> >>> > If you want staging to look like production, just push the
> >> >>> > production
> >> >>> > branch onto staging.
> >> >>> >
> >> >>> > $ git push -f origin production:staging
> >> >>> >
> >> >>> > --Hardy
> >> >>> >
> >> >>> >
> >> >>> ___
> >> >>> 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] JDK9 / WildFly / Validator issue with Search CI job

[Davide D';Alto]

I wonder if it's a problem of integration between Jenkins and the maven
failsafe plugin

On Wed, Jan 20, 2016 at 10:36 AM, Sanne Grinovero 
wrote:

> I'm puzzled.
> There seems to be a javax.validation related issue which is failing
> the integration tests running on Arquillian / WildFly for the
> Hibernate Search / WildFly tests on JDK9.
>
>
> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>
> But more importantly.. anyone has a clue on why the build is marked as
> "SUCCESS" ?
>
> You actually have to notice the failures in the logs to figure out
> that it's not successful at all;
> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>
> 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

[hibernate-dev] [OGM] How to get the transaction id

[Davide D';Alto]

Hi,

for the implementation of the Neo4j remote dialect I need to get the
identifier of the transaction.
I suppose this is something that we will need for other dialect as well in
the future.
What's the proper way to get the transaction id or the transaction? Is it
via the TransactionDriver?

Once I have the transaction id, one possible solution is to pass it to the
method of the GridDialect interface using an addtional parameter,
TransactionContext, that could contain information about the running
transaction.

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

[hibernate-dev] HipChat rooms

[Davide D';Alto]

Hi,
lately there is some interest in OrientDB for Hibernate OGM.
This is not currently in the OGM roadmap but I wanted to help potential
contributros.

I've createad a room for OGM-855 using the JIRA funcitonality accessible by
Guests.
It seems though theat Guest cannot see the log of the room and that when a
user send me an invite it becomes part of the hibernate team.

Is that OK? Or do we have some limitation about accepting new users?
Am I doing something wrong?

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

Re: [hibernate-dev] HipChat rooms

[Davide D';Alto]

I was wrong about the log for guests, the HipChat documentation states:

"The room's chat history, including files, are only visible to guests from
the point they logged in. "

So, it's better than I thought


On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto  wrote:

> Hi,
> lately there is some interest in OrientDB for Hibernate OGM.
> This is not currently in the OGM roadmap but I wanted to help potential
> contributros.
>
> I've createad a room for OGM-855 using the JIRA funcitonality accessible
> by Guests.
> It seems though theat Guest cannot see the log of the room and that when a
> user send me an invite it becomes part of the hibernate team.
>
> Is that OK? Or do we have some limitation about accepting new users?
> Am I doing something wrong?
>
> Cheers,
> Davide
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Who deleted http://docs.jboss.org/hibernate/validator ?

[Davide D';Alto]

Links seems to be in the format x.y
At least looking at the links on
http://hibernate.org/validator/documentation/



On Fri, Feb 12, 2016 at 5:08 PM, Steve Ebersole  wrote:

> What's the level of versions for the validator docs on the server?  x.y?
>
> On Fri, Feb 12, 2016 at 10:59 AM Steve Ebersole 
> wrote:
>
> > If the old style guides were there after the release, but gone since I
> > uploaded yesterday then maybe my upload also affected the validator docs.
> > No idea how that could have happened though.
> >
> > Anyway, I checked an the validator release bundles do in fact contain the
> > docs.  I can work on restoring those.
> >
> > Sorry (if that really was me).
> >
> > On Fri, Feb 12, 2016 at 10:53 AM Steve Ebersole 
> > wrote:
> >
> >> But thats a completely different URL Vlad.  That is a UR to the
> >> hibernate.org server.  Not the doc server.
> >>
> >> On Fri, Feb 12, 2016 at 10:48 AM Vlad Mihalcea  >
> >> wrote:
> >>
> >>> The 5.1 docs are also missing too:
> >>>
> >>> http://hibernate.org/orm/documentation/5.1
> >>>
> >>> I remember I saw the old-style guide right after the 5.1 release.
> >>>
> >>> Vlad
> >>>
> >>> On Fri, Feb 12, 2016 at 6:44 PM, Steve Ebersole 
> >>> wrote:
> >>>
>  That's strange.  As far as I know we actually cannot delete from
>  there.  At
>  least I was not allowed to delete from orm/5.1 yesterday when I was
>  doing
>  work.
> 
>  As for restoring, I do not know if backups are kept.  We could open a
>  ticket and see.  If not, do y'all build docs into the release bundles?
>  That could be an option
> 
>  On Fri, Feb 12, 2016 at 10:31 AM Emmanuel Bernard <
>  emman...@hibernate.org>
>  wrote:
> 
>  > Apparently http://docs.jboss.org/hibernate/validator is gone from
> the
>  > documentation server. Anyone has an idea of how that could have
>  > happened?
>  > How to fix it would be very useful too, I'm not sure we have a full
>  > backup of all the documentation since the history of time.
>  >
>  > Emmanuel
>  > ___
>  > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [OGM] New dialect for Aache Ignite

[Davide D';Alto]

I just wanted to mention that some contributor created a couple of new
dialects for Hibernate OGM.
They are for the open source and commercial version of Apache Ignite (
http://ignite.apache.org/features/datagrid.html)

Forum post:
https://forum.hibernate.org/viewtopic.php?f=31&t=1042954

This is the project on GitHub:
https://github.com/Z-z-z-z/hibernate-ogm

Maybe it is time to start talk again about the contrib repository for OGM?

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

Re: [hibernate-dev] http://www.hibernatespatial.org/

[Davide D';Alto]

The user registered to the hibernate-spatial mailing list but none of his
messages
appeared in the archive.

On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole  wrote:

> Karel, a user was asking about problems using the hibernate-spatial mailing
> list on IRC which precipitated a discussion about how we want deal with
> these things moving forward.  For example, the
> http://www.hibernatespatial.org/ site is still up and running and really
> has no indication that the move to integrate Spatial into Hibernate proper
> was completed.  What do you want to have happen with that website/URL?
>
> As for other infrastructure, what would you like to have happen?  It seems
> like hibernate-spatial is a more user-focused mailing list, as opposed to a
> dev mailing list?  If so, Hibernate does not really do user mailing lists.
> We prefer the forums or StackOverflow for user questions, so there is not a
> straight "migration".  You can obviously keep the hibernate-spatial mailing
> list running too, but we should have some idea how to help users who are
> having trouble with it on the website (which website depends on what you
> decide to do with http://www.hibernatespatial.org/.
>
> Any other things we should discuss in terms of infrastructure?
>
> Davide, what was the exact problem the user on IRC was complaining about
> wrt the hibernate-spatial mailing list?
> ___
> 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] Trouble with blog for ORM 5.0.9

[Davide D';Alto]

> The build ran exceptionally long (52 min, see here:
> http://ci.hibernate.org/view/Website/job/in.relation.to/buildTimeTrend
).
> I'm not sure why, let's hope it was a one-time issue.

It seems to happen more often lately.
The same thing happened for the release of beanvalidation.org:
http://ci.hibernate.org/job/beanvalidation.org/buildTimeTrend
I suspect sometimes OS1 gets too much work and tends to slow down.




On Tue, Mar 15, 2016 at 8:46 AM, Vlad Mihalcea 
wrote:

> I announced the release on Twitter.
>
> Vlad
>
> On Tue, Mar 15, 2016 at 10:17 AM, Gunnar Morling 
> wrote:
>
> > Hi Gail,
> >
> > Your post is there:
> > http://in.relation.to/2016/03/14/hibernate-orm-509-final-release/
> >
> > The build ran exceptionally long (52 min, see here:
> > http://ci.hibernate.org/view/Website/job/in.relation.to/buildTimeTrend).
> > I'm not sure why, let's hope it was a one-time issue.
> >
> > Regarding your local error, it's not clear from that message.
> > Appending "--trace" would help to reveal more information should the
> > issue remain.
> >
> > --Gunnar
> >
> >
> >
> > 2016-03-15 6:27 GMT+01:00 Gail Badner :
> > > Hibernate ORM 5.0.9.Final is released. Everything is done except the
> > > announcements.
> > >
> > > I did `rake preview` and saw that my blog displayed correctly locally,
> > so I
> > > cherry-picked the commit with my blog to production and pushed the
> > commit.
> > > It's been over an hour and I still don't see it on
> > http://in.relation.to/.
> > >
> > > I tried `rake clean preview` on the production branch and now I see:
> > >
> > >
> >
> ***
> > > Starting preview server at http://localhost:4242 (Press Ctrl-C to
> > shutdown)
> > >
> >
> ***
> > > [2016-03-14 22:23:50] INFO  WEBrick 1.3.1
> > > [2016-03-14 22:23:50] INFO  ruby 2.2.1 (2015-02-26) [x86_64-linux]
> > > rake aborted!
> > > ERROR: Running Awestruct failed.
> > > /home/gbadner/git/in.relation.to-again/Rakefile:104:in `run_awestruct'
> > > /home/gbadner/git/in.relation.to-again/Rakefile:64:in `block in  > > (required)>'
> > > /home/gbadner/.rvm/gems/ruby-2.2.1/bin/ruby_executable_hooks:15:in
> `eval'
> > > /home/gbadner/.rvm/gems/ruby-2.2.1/bin/ruby_executable_hooks:15:in
> > `'
> > > Tasks: TOP => preview
> > > (See full trace by running task with --trace)
> > >
> > > Anyone have any idea what is wrong?
> > >
> > > Thanks,
> > > Gail
> > > ___
> > > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [HSEARCH] Rename elasticsearch artifact

[Davide D';Alto]

At the moment the elasticsearch integration artifactid is:

hibernate-search-backend-elasticsearch

Elasticsearch is actually more than just a backend (we use this term for
the jGroups and JMS integration). I think we should rename it to:

hibernate-search-elasticsearch


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

Re: [hibernate-dev] Blog tag vs categories

[Davide D';Alto]

The problem with having many tags is that you will have a huge tag cloud
with just a few words more visible than the others.
This was the case before we did some clean up. In our case it also becomes
hard to keep track of the tags we already used
with the result of several duplicates.

Now that I think about it, didn't we have a validation in place for tags?




On Mon, Mar 21, 2016 at 1:51 PM, Sanne Grinovero 
wrote:

> Sorry that restriction wasn't clear to me.
>
> Could we wait some time before deleting it?
> I'm afraid I shared that link on social media, e.g. the Elasticsearch
> forums.
>
> BTW It's not clear to me why you fear an explosion; having a tag cloud
> is not uncommon on blogs, and is based on the idea of having many such
> tags.
>
>
> On 21 March 2016 at 09:28, Emmanuel Bernard 
> wrote:
> > It looks like you have created the elasticsearch tag in the blog
> > http://in.relation.to/elasticsearch/
> >
> > I thought we had decided to use tags more as well defined categories:
> >
> > * the projects or specs we work on
> > * 'Events', 'Releases', 'Discussion', 'Off-topic'
> >
> > Do you really think we should extend to projects we use as third-party? I
> > fear an explosion and would prefer to remove the 'elasticsearch' tag.
> >
> > Emmanuel
> > ___
> > 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] Blog tag vs categories

[Davide D';Alto]

> I'm ok to remove it, but I don't buy that reason: it sounds more like a
technical limitation than something which should affect our capability to
produce good content.

The lack of validation of the tags is a technical limitation, and should
not be too hard to add,
keeping the words in the cloud limited is a usability aspect.
Would you also add Neo4j, CouchDB, Redis and so on for OGM?

It's OK for me if we want to extend the number of keywords in the tag
cloud, but I don't think
it's a good idea to make it possible to add new keyword each time.

> BTW, Davide, I've seen "Off topic" and "Off-topic" I could not find the
one
mapped "Off topic", I don't know if you have an idea how to.

I'll check

On Mon, Mar 21, 2016 at 3:00 PM, Emmanuel Bernard 
wrote:

> On Mon 2016-03-21 14:26, Sanne Grinovero wrote:
> > On 21 March 2016 at 14:10, Davide D'Alto  wrote:
> > > The problem with having many tags is that you will have a huge tag
> cloud
> > > with just a few words more visible than the others.
> > > This was the case before we did some clean up. In our case it also
> becomes
> > > hard to keep track of the tags we already used
> > > with the result of several duplicates.
> >
> > I'm ok to remove it, but I don't buy that reason: it sounds more like
> > a technical limitation than something which should affect our
> > capability to produce good content.
>
> Davide and I did all the clean up work last time. We would prefer not
> have to do it again. The previous tag cloud was useless. The current one
> is already pretty crowded to be honest.
>
> BTW, Davide, I've seen "Off topic" and "Off-topic" I could not find the one
> mapped "Off topic", I don't know if you have an idea how to.
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Blog tag vs categories

[Davide D';Alto]

It seems that "Off-topic" and  "Off topic" are basically the same tag, they
both point to:
http://in.relation.to/off-topic/index.html

It's probably a bug in the tag cloud generation

On Mon, Mar 21, 2016 at 3:13 PM, Davide D'Alto 
wrote:

> > I'm ok to remove it, but I don't buy that reason: it sounds more like a
> technical limitation than something which should affect our capability to
> produce good content.
>
> The lack of validation of the tags is a technical limitation, and should
> not be too hard to add,
> keeping the words in the cloud limited is a usability aspect.
> Would you also add Neo4j, CouchDB, Redis and so on for OGM?
>
> It's OK for me if we want to extend the number of keywords in the tag
> cloud, but I don't think
> it's a good idea to make it possible to add new keyword each time.
>
> > BTW, Davide, I've seen "Off topic" and "Off-topic" I could not find the
> one
> mapped "Off topic", I don't know if you have an idea how to.
>
> I'll check
>
> On Mon, Mar 21, 2016 at 3:00 PM, Emmanuel Bernard 
> wrote:
>
>> On Mon 2016-03-21 14:26, Sanne Grinovero wrote:
>> > On 21 March 2016 at 14:10, Davide D'Alto  wrote:
>> > > The problem with having many tags is that you will have a huge tag
>> cloud
>> > > with just a few words more visible than the others.
>> > > This was the case before we did some clean up. In our case it also
>> becomes
>> > > hard to keep track of the tags we already used
>> > > with the result of several duplicates.
>> >
>> > I'm ok to remove it, but I don't buy that reason: it sounds more like
>> > a technical limitation than something which should affect our
>> > capability to produce good content.
>>
>> Davide and I did all the clean up work last time. We would prefer not
>> have to do it again. The previous tag cloud was useless. The current one
>> is already pretty crowded to be honest.
>>
>> BTW, Davide, I've seen "Off topic" and "Off-topic" I could not find the
>> one
>> mapped "Off topic", I don't know if you have an idea how to.
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [OGM] Retrieve byte[] as streams in MongoDB

[Davide D';Alto]

Hi,
I've seent this question on stack overflow and I was wondering if there is
any way to do what he asks:
http://stackoverflow.com/questions/36134440/mongodb-get-byte-as-streams-in-java

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

[hibernate-dev] [OGM] Any idea for OGM-1000?

[Davide D';Alto]

Next JIRA will be OGM-1000, any interesting idea we should use for this
ticket?

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

Re: [hibernate-dev] [OGM] Retrieve byte[] as streams in MongoDB

[Davide D';Alto]

Damn, you discovered my secret identity :)

(I meant "seen" by the way)

On Wed, Mar 23, 2016 at 5:18 PM, Emmanuel Bernard 
wrote:

> Seent means seen or sent? If the latter we found one of your secret
> identities ;)
>
> On Tue 2016-03-22 11:13, Davide D'Alto wrote:
> > Hi,
> > I've seent this question on stack overflow and I was wondering if there
> is
> > any way to do what he asks:
> >
> http://stackoverflow.com/questions/36134440/mongodb-get-byte-as-streams-in-java
> >
> > Thanks,
> > Davide
> > ___
> > 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] Using Java8 language features in OGM/HotRod

[Davide D';Alto]

Yeah, go with it.
I don't think it is going to be too hard to fix the conflicts in the Neo4j
module.

>TLRD:

Did you mean: TLDR;


On Wed, Mar 23, 2016 at 7:02 PM, Gunnar Morling 
wrote:

> +1 for fixing these things, I also was wondering about some apparent style
> violations which CS failed to report. Must have been these bug fixes then.
>
> The only thing coming to my mind is Davide's work which may change things
> in the existing Neo4j code. Maybe you two quickly sync? Apart from that I'd
> say let's do it.
>
> 2016-03-23 19:57 GMT+01:00 Sanne Grinovero :
>
> > TLRD: don't be surprised if I'll be sending some rather large code
> > style fixes. Not wasting my time nor intending to waste yours..
> >
> >
> > I've been writing quite some code enjoying Java 8 specific features in
> > the new OGM module,
> > as I assumed this would not be an issue at all since Hot Rod requires
> > Java8 and we require Java8 to build anyway.
> >
> > Unfortunately the Checkstyle plugin crashes when it encounters Java8
> > bytecode ops, something which is easily fixed with a plugin upgrade.
> > The plugin upgrade however *fixed* some bugs in Checkstyle, for which
> > it had been accepting some syntax even though we were explicitly
> > intending to guard against these.
> >
> > So now there are several (~300) style failures; these are legitimate
> > failures so my plan is to fix these.
> >
> > If someone is busy with some rather large refactoring, please speak up
> > now as I can wait with this, or we can stagger this cleanup by sending
> > the fixes for some modules only, and the remaining later.
> >
> > P.S. I'd rather cleanup the bad code than revert my Java8 code.. both
> > as a lesser effort, and as a better ultimate result.
> >
> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Using Java8 language features in OGM/HotRod

[Davide D';Alto]

 > probably. Or make you doubt, so to make you read it all..

The trick is to put it at the end :)

(TLDR; = Too Long, Didn't Read;)

On Wed, Mar 23, 2016 at 7:12 PM, Sanne Grinovero 
wrote:

> On 23 March 2016 at 19:07, Davide D'Alto  wrote:
> > Yeah, go with it.
> > I don't think it is going to be too hard to fix the conflicts in the
> Neo4j
> > module.
>
> Ok, thanks:
>  - https://hibernate.atlassian.net/browse/OGM-1001
>
> >
> >>TLRD:
> >
> > Did you mean: TLDR;
>
> probably. Or make you doubt, so to make you read it all..
>
> Sanne
>
>
> >
> >
> > On Wed, Mar 23, 2016 at 7:02 PM, Gunnar Morling 
> > wrote:
> >>
> >> +1 for fixing these things, I also was wondering about some apparent
> style
> >> violations which CS failed to report. Must have been these bug fixes
> then.
> >>
> >> The only thing coming to my mind is Davide's work which may change
> things
> >> in the existing Neo4j code. Maybe you two quickly sync? Apart from that
> >> I'd
> >> say let's do it.
> >>
> >> 2016-03-23 19:57 GMT+01:00 Sanne Grinovero :
> >>
> >> > TLRD: don't be surprised if I'll be sending some rather large code
> >> > style fixes. Not wasting my time nor intending to waste yours..
> >> >
> >> >
> >> > I've been writing quite some code enjoying Java 8 specific features in
> >> > the new OGM module,
> >> > as I assumed this would not be an issue at all since Hot Rod requires
> >> > Java8 and we require Java8 to build anyway.
> >> >
> >> > Unfortunately the Checkstyle plugin crashes when it encounters Java8
> >> > bytecode ops, something which is easily fixed with a plugin upgrade.
> >> > The plugin upgrade however *fixed* some bugs in Checkstyle, for which
> >> > it had been accepting some syntax even though we were explicitly
> >> > intending to guard against these.
> >> >
> >> > So now there are several (~300) style failures; these are legitimate
> >> > failures so my plan is to fix these.
> >> >
> >> > If someone is busy with some rather large refactoring, please speak up
> >> > now as I can wait with this, or we can stagger this cleanup by sending
> >> > the fixes for some modules only, and the remaining later.
> >> >
> >> > P.S. I'd rather cleanup the bad code than revert my Java8 code.. both
> >> > as a lesser effort, and as a better ultimate result.
> >> >
> >> > 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
> >
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Any idea for OGM-1000?

[Davide D';Alto]

I like the name ScenicView, but it seems there is already a project using
it: http://fxexperience.com/scenic-view/

StrikingView?

On Wed, Mar 23, 2016 at 6:48 PM, Sanne Grinovero 
wrote:

> On 23 March 2016 at 18:37, Gunnar Morling  wrote:
> > Hi,
> >
> > That's a very good question and we need to decide.
> >
> > In the PoC I'm working on, I started from scratch in a separate project
> for
> > some reasons:
> >
> > * I wanted to have a clean slate, not being influenced by the complexity
> and
> > patterns living in existing grid dialects
> > * Freedom to use Java 8 with Lambdas etc.
>
> Funny, was just needing the same and having issues with getting that
> to work within OGM. I'll send a separate email on that.
>
> > * So far, what I need from "backends" is much less than what's provided
> by
> > OGM grid dialects, but on the other hand it's more powerful already: I
> found
> > (so I hope) a nice way to pass entire aggregate trees (and collections
> > thereof), which then can e.g. be written in a single op to the store,
> much
> > simpler than the current effort we need to do in OGM dialects for e.g.
> > embedding association info
> > * I'd like to build a backend for Postgres + JSON without having to
> > implement a full OGM dialect for this
> >
> > That all being said, I'll share what I have with you very soon and we can
> > discuss it from there.
> >
> > --Gunnar
> >
> > PS: We seem to switch between "ScenicDrive" and "ScenicView" ;) In my
> PoC I
> > went for the latter.
>
> One is the engine name, the other the API ;-)
>
> Jokes aside, yes I also expected it to be a separate project.
>
> I wonder if you're going to have better decision elements after your
> POC, or if having the POC separate is setting the first irreversible
> note.
> Some people suggest that a POC should always be thrown away and
> rewritten...
>
> Sanne
>
> >
> >
> >
> >
> >
> > 2016-03-23 19:28 GMT+01:00 Sanne Grinovero :
> >>
> >> On 23 March 2016 at 17:18, Emmanuel Bernard 
> >> wrote:
> >> > Is ScenicDrive captured?
> >>
> >> Interesting. You suggest that ScenicDrive is a feature of OGM ?
> >>
> >> >
> >> > On Tue 2016-03-22 11:29, Davide D'Alto wrote:
> >> >> Next JIRA will be OGM-1000, any interesting idea we should use for
> this
> >> >> ticket?
> >> >>
> >> >> Cheers,
> >> >> Davide
> >> >> ___
> >> >> 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
> >
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Reduce the integrationtest directiry size

[Davide D';Alto]

Yes, I'll have a look at this

Davide

On Thu, Mar 24, 2016 at 7:38 AM, Gunnar Morling 
wrote:

> 2016-03-24 8:24 GMT+01:00 Emmanuel Bernard :
>
> > I noticed that for each integration test module we do download a full
> > Wildfly distribution. Since we are having more and more integration test
> > module it adds up significantly. On top of that the integrationtest
> module
> > itself also downloads Wildfly. The current size is of integrationtest is
> > 1.3 GB with most of it attributed to Wildfly. Could we share the same
> > download somehow ?
> >
>
> There is the idea to move all the integration tests into a single module
> for the sake of reducing overall test runtime: Currently the server is
> started/stopped once for each of the integration test modules.
>
> This would be reduced to one such cycle, as a side-effect only one download
> would be needed, too. I thought there is an issue for that, but can't find
> it right now.
>
> @Davide, maybe you could check out this one if you need a break from the
> Neo4j work?
>
>
> >
> > On a side note, what are the ORM
> > target/test-results/binary/test/output.bin? In my quest for more space I
> > stumbled upon them.
> >
> > Emmanuel
> > ___
> > 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

[hibernate-dev] [OGM] Preparing release 5.0.0.CR1

[Davide D';Alto]

I've moved the missing issues on the jira to the next next version but I
don't think it's a good idea to make the release and the blog post before
the Easter holidays.

I'm going to complete the release on Tuesday, so. if there is something you
want to include you still have time.

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