Re: [hibernate-dev] OGM: CheckStyle and imports due to JavaDoc comments

[Emmanuel Bernard]

For the record, I side with Gunnar in relaxing this. I actually did not see 
this thread and opened a issue for it this very morning.
In most situations we reference classes local to the module via {@link} and the 
fully qualified class name is very annoying and very long.


On 31 juil. 2013, at 09:33, Gunnar Morling wrote:

> Hi,
> 
> Currently CheckStyle raises an error due to an "unused import" if a class
> imports types which are only referenced in JavaDoc comments. This issue
> occurs for instance when referring to a super type in the comments while
> only sub-types are used in the actual code:
> 
>/**
> * This factory creates {@link Service} objects.
> */
>public class ServiceFactory {
> 
>FooService getFooService() { ... }
>}
> 
> Another example is "high-level" documentation on a central type of an API
> (e.g. its entry point) which refers to types actually used by specific
> parts of the API but not the entry point itself. In that case it can still
> make sense to mention these types in the high-level docs.
> 
> To work around the issue one could use the FQN in the JavaDoc or just
> format it as {@code}, but both makes up for less readable documentation IMO.
> 
> Personally I don't see a problem with this kind of import and thus suggest
> to loosen that CS rule accordingly (it can be configured to take JavaDocs
> into account). WDYT?
> 
> --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: CheckStyle and imports due to JavaDoc comments

[Emmanuel Bernard]

On 31 juil. 2013, at 13:14, Hardy Ferentschik wrote:

> 
> On 31 Jan 2013, at 10:41 AM, Gunnar Morling  wrote:
> 
>> Personally I prefer to include a class via fully qualified name if it is 
>> only used in the javadocs.
>> I think the readability does not suffer too much and adding an actual import 
>> has actually
>> runtime consequences. We already had cases where a javadoc import caused a 
>> hard link
>> between code which is otherwise decoupled.
>> 
>> WDYM exactly by "hard link" in this context? Is it about referencing a type 
>> from an optional dependency which might not be present at runtime?
> 
> Right, optional dependencies. Take JPA and Search. In the engine module we 
> avoid importing it directly and do processing of
> @Id reflectively. Having an import of javax.persitence.Id would create a 
> runtime dependency.
> 
>> I just tried out this scenario (adding an import statement just for JavaDoc 
>> to a type which is not present at runtime) and still could execute the 
>> importing class
>> without problems. Only when accessing the imported type in the actual code 
>> I'm getting a CNFE. But this might be specific to the VM in use, not sure.
> 
> We had this discussion now several times. I remember when we wrote this 
> reflection code the first time (many years back ;-))
> all referenced classes were eagerly loaded. In this case just having the 
> import statement required the class being 
> available at runtime.  Obviously this must have changed a bit which also is 
> proven by your experiment. 
> 

Of course my memory might be flawed but the problems I recall around isolating 
a piece of code for hv, search and later bean validation from core did not 
involve unused imports. Come to think of it, I have never seen an *unused* 
import eagerly loading a class even though in practice it's left unspecified by 
the JLS.



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

Re: [hibernate-dev] OGM: CheckStyle and imports due to JavaDoc comments

[Emmanuel Bernard]

On Thu 2013-08-01 11:41, Hardy Ferentschik wrote:
> Why? The few occasions where it happens a fully qualified class name does not 
> hurt. 
> It is not enough that it is considered bad practise and even Checkstyle for 
> that 
> reason does not allow it in the UnusedImports check?

I actually do find it does hurt to have the fqcn in the JavaDoc as
reading the JavaDoc from the source is probably 50% of the usage.

Does it hurt enough that it outweighs the possible violation? I think it
does.

Note that the author of this rule did consider it bad practice but either
wasn't sure enough or had enough backlash that he did put an option to
change the behavior :)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] unit test PSA

[Emmanuel Bernard]

What's PSA? Pakistan Society of Anaesthesiologists?
http://www.acronymfinder.com/PSA.html

Emmanuel

On Mon 2013-08-05 16:49, Brett Meyer wrote:
> A friendly PSA regarding unit tests...
> 
> I spent the afternoon cleaning up tests that were failing in our matrix CI 
> job.  There were lots of failures on various DBs due to the following:
> 
> 1.) Columns referenced by a UK/PK must NOT be nullable.
> 2.) Tests that solely use ConnectionProviderBuilder in the Configuration 
> (pure unit tests, not functional tests) should use "@RequiresDialectFeature( 
> value = ConnectionProviderBuilder.class )".  ConnectionProviderBuilder now 
> extends DialectCheck.  The Dialect used by ConnectionProviderBuilder 
> (currently H2) will therefore be required and all others skipped.
> 3.) Avoid the use of reserved keywords ("User", "Table", "Comment", etc.).  
> If it seems like it's possible for it to be reserved somewhere, please avoid.
> 4.) Table and column name lengths, including collection tables, should be 
> less than 30 characters.  This was mainly an issue with entities embedded in 
> the test class (implicit name is ParentClass$SubClass).
> 
> https://hibernate.atlassian.net/browse/HHH-8420
> 
> If everyone could keep those in mind, I'd sincerely appreciate it.  It 
> removes time-consuming debugging later on (although I realize that most of 
> those are very dialect-specific).  Thanks!
> ___
> 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] [Search] Why is global @AnalyzerDefs scanning limited to @Entity?

[Emmanuel Bernard]

To me the real answer is to the programmatic API and add a
programmatic mapping factory to your configuration.

See Example 4.28. Use a mapping factory in
http://docs.jboss.org/hibernate/search/4.4/reference/en-US/html_single/#hsearch-mapping-programmaticapi

On Thu 2013-06-20 18:22, Guillaume Smet wrote:
> Hi,
> 
> We would like to declare our global @AnalyzerDefs on a class which
> isn't a specific entity.
> 
> For the @TypeDefs of Hibernate, we do it by declaring the @TypeDefs on
> a class annotated with @MappedSuperClass but with @AnalyzerDefs, we
> are forced to declare them on a concrete @Entity.
> 
> Is this an oversight or something due to the way the initialization of
> Hibernate Search is done and we cannot change?
> 
> I know it's only cosmetic but it's a bit ugly to have a dummy entity
> and a dummy table in our core framework just to be able to declare
> global @AnalyzerDefs.
> 
> Thanks for your feedback.
> 
> -- 
> 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

Re: [hibernate-dev] HSEARCH - Different analyzers for Indexing and Querying

[Emmanuel Bernard]

It looks like an interesting idea especially as it keep the simple use
case simple (ie simply not defining an queryAnalyzer.

Can you explain to me why you would need a different analyzer for a
wildcard query? My brain is still tanning on the beach.

Brainstorming here we could do the following

@AnalyzerDef.target

enum AnalyzerTarget { ALL, INDEXING, QUERY, WILDCARD }

So you could define the same @AnalyzerDef.name several times provided
that they did not share the same targets.

But that would also change the API for the dynamic analyzer I suppose.
It also does not cover the @Analyzer.impl usage.

On Tue 2013-08-13 10:13, Guillaume Smet wrote:
> Hi,
> 
> Note: this is just a prospective idea I'd like to discuss. Even if
> it's a good idea, it's definitely 5.0 material.
> 
> Those who have used Solr and are familiar with the Solr schema have
> already seen the ability to use different analyzer for indexing and
> querying.
> 
> It's usually useful when you use analyzers which returns several
> tokens for a given token: the QueryParser usually can't build the
> correct query with these analyzers.
> 
> To take an example from my current work on HSEARCH-917 (soon to come
> \o/), I have the following case. From i-pod , the analyzer builds ipod
> i pod i-pod. ipod and i-pod aren't the issue here but the fact that i
> pod is on two tokens makes the QueryParser build an incorrect query
> (even if I use the Lucene 4.4 version which is a little bit smarter
> about these cases and at least make the i-pod ipod case work
> correctly).
> 
> The fact is that if the analyzer used at indexing has correctly
> indexed all the tokens, I don't need to expand the terms at querying
> and it should be sufficient to use a simple analyzer to lowercase the
> string and remove the accents.
> 
> Solr introduced this feature a long time ago (it was already there in
> the good old times of 1.3) and I'm wondering if we shouldn't introduce
> it in Hibernate Search too.
> 
> As for the implementation, I was thinking about adding an attribute
> queryAnalyzer to the @Field annotation. I was also wondering if we
> shouldn't add the ability to define an Analyzer for wildcard queries
> (Lucene introduced recently an AnalyzingQueryParser to do something
> like that).
> 
> And maybe, in this case, it would be a good idea to centralize the
> configuration with types as it's done in Solr? Usually, the three
> analyzers definitions would come together.
> 
> As for my particular needs, most of my full text fields would be
> analyzed like this:
> 
> indexing:
>   @AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
>   tokenizer = @TokenizerDef(factory = 
> WhitespaceTokenizerFactory.class),
>   filters = {
>   @TokenFilterDef(factory = 
> ASCIIFoldingFilterFactory.class),
>   @TokenFilterDef(factory = 
> WordDelimiterFilterFactory.class, params = {
>   
> @org.hibernate.search.annotations.Parameter(name =
> "generateWordParts", value = "1"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "generateNumberParts", value = "1"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "catenateWords", value = "1"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "catenateNumbers", value = "0"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "catenateAll", value = "0"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "splitOnCaseChange", value = "0"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "splitOnNumerics", value = "0"),
>   
> @org.hibernate.search.annotations.Parameter(name =
> "preserveOriginal", value = "1")
>   }
>   ),
>   @TokenFilterDef(factory = 
> LowerCaseFilterFactory.class)
>   }
>   ),
> querying:
>   @AnalyzerDef(name = HibernateSearchAnalyzer.TEXT,
>   tokenizer = @TokenizerDef(factory = 
> StandardTokenizerFactory.class),
>   filters = {
>   @TokenFilterDef(factory = 
> ASCIIFoldingFilterFactory.class),
>   @TokenFilterDef(factory = 
> LowerCaseFilterFactory.class)
>   }
>   ),
> wildcard:
>   @AnalyzerDef(name = HibernateSearchAnaly

Re: [hibernate-dev] HSEARCH - Different analyzers for Indexing and Querying

[Emmanuel Bernard]

On Thu 2013-08-22 13:40, Guillaume Smet wrote:
> Hi Emmanuel,
> 
> On Wed, Aug 21, 2013 at 5:20 PM, Emmanuel Bernard
>  wrote:
> > Can you explain to me why you would need a different analyzer for a
> > wildcard query? My brain is still tanning on the beach.
> 
> Well, it's the Lucene way. Wildcard queries are usually not analyzed
> (see QueryParser or what you've done in Hibernate Search to be
> consistent with Lucene).
> 
> The reason often mentioned is that you can have analyzers removing *
> and ? which could be quite annoying for wildcard queries...
> 
> Apart from the filtering, you might also want a different tokenizer
> for wildcard queries.
> 
> The fact is that you HAVE to "analyze" your search terms to have
> results. Typically, we use analyzers to remove the accents and
> lowercase the search terms:
> - for a standard search, we can pass the search terms as is;
> - for the wildcard and fuzzy queries, we are forced to filter the
> search terms (lowercase + remove accents) before passing them to
> Hibernate Search/Lucene.
> 
> That's why I thought having a specific analyzer for this might help.

Oh ok, btw I think I do disable analyzers in the DSL query right? Of
course we might want to reenable it if a specific wildcard analyzer is
defined.

> 
> > Brainstorming here we could do the following
> >
> > @AnalyzerDef.target
> >
> > enum AnalyzerTarget { ALL, INDEXING, QUERY, WILDCARD }
> 
> Instead of ALL, I would prefer DEFAULT, I think.
> 
> > But that would also change the API for the dynamic analyzer I suppose.
> 
> Yep,
> 
> > It also does not cover the @Analyzer.impl usage.
> 
> Yep.
> 
> I haven't thought thoroughly about all the consequences of this idea.
> It's something which is often in our way so I thought it might be
> worth it to mention it and see if people are interested in it.
> 
> If so, I can probably prototype something to check what would be the
> issues to implement this change.

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

[hibernate-dev] [HSEARCH] Using two level queries to fight stop word disease

[Emmanuel Bernard]

The elasticsearch guys have done something quite smart

http://www.elasticsearch.org/blog/stop-stopping-stop-words-a-look-at-common-terms-query/

Basically combine a classic query with a query with the stop words. And stop 
words are defined by their frequency. 

Anyone want to implement something similar and play with it to see of that's 
useful in practice ?

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

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

[Emmanuel Bernard]

My initial reaction was to go for 1. but I forgot that the parser is now
reused by ISPN. I'd go for 2. then.

Emmanuel

On Tue 2013-08-27 11: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

Re: [hibernate-dev] JPA API jar artifacts

[Emmanuel Bernard]

+1 to have a suffix not related tot he draft. Like you I have pushed
spec jars that did not reflect eh state of a draft necessarily.

BTW, why retrofit that scheme? Why not just apply it for 2.1?

Emmanuel

On Tue 2013-08-27  9:57, Steve Ebersole wrote:
> I am contemplating duplicating[1] our existing JPA API jars to use a 
> better GAV naming scheme, specifically the GAV naming scheme we plan on 
> adopting for any new JPA specs.  We have used completely different 
> naming scheme for 1.0 then we did for 2.0 and 2.1.  And even for 2.0 and 
> 2.1 we used the JPA version in the artifactId rather than the version 
> portion of GAV.
> 
> The new scheme being proposed would be to use the groupId we have been 
> using for 2.0/2.1 ("org.hibernate.javax.persistence").  We would use the 
> artifactId we have been using for 2.0/2.1, but without the 2.0/2.1 
> portion.  Currently, for example, we have "hibernate-jpa-2.1-api" as the 
> artifactId; this would become just "hibernate-jpa-api".  We'd then move 
> the JPA version as *part of* the GAV version.  Essentially the GAV 
> version would be broken into buckets with JPA version taking up the 
> first 2 positions, a "bugfix" position, and then a qualifier.  Given 
> 1.0, 2.0 and 2.1 that would give us:
> 1) org.hibernate.javax.persistence:hibernate-jpa-api:1.0.0.Final.jar
> 2) org.hibernate.javax.persistence:hibernate-jpa-api:2.0.0.Final.jar
> 3) org.hibernate.javax.persistence:hibernate-jpa-api:2.1.0.Final.jar
> 
> I would only duplicate the last of each of 1.0, 2.0 and 2.1 into the new 
> naming.
> 
> Moving forward, the only thing that "changes" would be qualifiers if/as 
> we start working on new spec versions and possibly "bugfix" portion (the 
> last '0') if we encounter problems in the jpa api jars after the fact 
> (normal bugfix semantics).  We are discussing standardizing on this 
> across the JBoss community and specifically discussing how to handle the 
> qualifiers for ongoing work.  One option would be a new qualifier 
> "Draft".  It fits reasonably well in the existing (OSGi defined) alpha 
> sorting of qualifiers aside from the Draft->Final jump (what about 
> "Proposed Final Drafts"?). Personally I do not like the direct tie to 
> specific spec Drafts; personally I know sometimes I publish spec jars 
> that do not cleanly map to a Draft.  I personally prefer using Beta for 
> Drafts, CR for Proposed Final Drafts  and Final for, well, Final 
> Drafts.  We'll have to see how that works itself out though.
> 
> Anyway, any issues/concerns with duplicating these historical artifacts?
> 
> [1] I am thinking of duplicating rather than "relocating" since I am not 
> sure how well tools handle relocated artifacts in general.  In fact I 
> think tools (Maven itself included) simply fail to resolve the relocated 
> artifact.
> 
> 
> 
> ___
> 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] JPA API jar artifacts

[Emmanuel Bernard]

On Tue 2013-08-27 10:22, Steve Ebersole wrote:
> On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard wrote:
> >+1 to have a suffix not related tot he draft. Like you I have pushed
> >spec jars that did not reflect eh state of a draft necessarily.
> >
> >BTW, why retrofit that scheme? Why not just apply it for 2.1?
> 
> Well applying it for 2.1 is in fact retrofitting it too.  I have
> already pushed the 2.1 "Final".  As for why 1.0 and 2.0 also, I just
> like consistency; it makes me happy :)
> 

If that makes you happy to fight Nexus, that makes me happy to watch you
;)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JPA API jar artifacts

[Emmanuel Bernard]

Technically the spec could go in what is called maintenance mode. In
which case the spec lead could use micro or some prefix like M1.
But we don't know if that will happen for JPA nor which one will be
chosen.

Emmanuel

On Tue 2013-08-27 10:55, Steve Ebersole wrote:
> I don't ever foresee that happening.  I don't know that it is 
> "guaranteed" anywhere though.
> 
> On 08/27/2013 10:29 AM, Gunnar Morling wrote:
> > Sounds reasonable to me.
> >
> > One question only: It is guaranteed that the JPA spec itself never 
> > will do a micro update, right? I.e. the spec would never be updated 
> > from say 2.2 to 2.2.1 (but to 2.3 in this case)?
> >
> >
> > 2013/8/27 Steve Ebersole  > >
> >
> > I am contemplating duplicating[1] our existing JPA API jars to use a
> > better GAV naming scheme, specifically the GAV naming scheme we
> > plan on
> > adopting for any new JPA specs.  We have used completely different
> > naming scheme for 1.0 then we did for 2.0 and 2.1.  And even for
> > 2.0 and
> > 2.1 we used the JPA version in the artifactId rather than the version
> > portion of GAV.
> >
> > The new scheme being proposed would be to use the groupId we have been
> > using for 2.0/2.1 ("org.hibernate.javax.persistence").  We would
> > use the
> > artifactId we have been using for 2.0/2.1, but without the 2.0/2.1
> > portion.  Currently, for example, we have "hibernate-jpa-2.1-api"
> > as the
> > artifactId; this would become just "hibernate-jpa-api".  We'd then
> > move
> > the JPA version as *part of* the GAV version.  Essentially the GAV
> > version would be broken into buckets with JPA version taking up the
> > first 2 positions, a "bugfix" position, and then a qualifier.  Given
> > 1.0, 2.0 and 2.1 that would give us:
> > 1) org.hibernate.javax.persistence:hibernate-jpa-api:1.0.0.Final.jar
> > 2) org.hibernate.javax.persistence:hibernate-jpa-api:2.0.0.Final.jar
> > 3) org.hibernate.javax.persistence:hibernate-jpa-api:2.1.0.Final.jar
> >
> > I would only duplicate the last of each of 1.0, 2.0 and 2.1 into
> > the new
> > naming.
> >
> > Moving forward, the only thing that "changes" would be qualifiers
> > if/as
> > we start working on new spec versions and possibly "bugfix"
> > portion (the
> > last '0') if we encounter problems in the jpa api jars after the fact
> > (normal bugfix semantics).  We are discussing standardizing on this
> > across the JBoss community and specifically discussing how to
> > handle the
> > qualifiers for ongoing work.  One option would be a new qualifier
> > "Draft".  It fits reasonably well in the existing (OSGi defined) alpha
> > sorting of qualifiers aside from the Draft->Final jump (what about
> > "Proposed Final Drafts"?). Personally I do not like the direct tie to
> > specific spec Drafts; personally I know sometimes I publish spec jars
> > that do not cleanly map to a Draft.  I personally prefer using
> > Beta for
> > Drafts, CR for Proposed Final Drafts  and Final for, well, Final
> > Drafts.  We'll have to see how that works itself out though.
> >
> > Anyway, any issues/concerns with duplicating these historical
> > artifacts?
> >
> > [1] I am thinking of duplicating rather than "relocating" since I
> > am not
> > sure how well tools handle relocated artifacts in general.  In fact I
> > think tools (Maven itself included) simply fail to resolve the
> > relocated
> > artifact.
> >
> >
> >
> > ___
> > 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] Dropping "hibernate-ogm" prefix from folder names

[Emmanuel Bernard]

Yes after 208 is in seems the best time. Don't worry too much about the
other backend PRs,t hey are obsolete I suppose but I don't want to lose
the work entirely.
On Thu 2013-08-29 10:14, Gunnar Morling wrote:
> Hi,
> 
> I'd like to remove the prefix "hibernate-ogm" from the folder names of the
> OGM modules [1]. This will make navigating in a shell easier and also
> aligns the structure of the code base with HSEARCH and HV. Note that this
> is only about folder names, the artifact ids would stay unchanged.
> 
> If no-one objects to the change itself, my question is when it should be
> done, as it may cause some work with rebasing in-flight pull requests that
> add new files. Rebasing such a PR after the folder renaming will cause any
> new files to be still created at the old location and thus requires some
> manual work (changes to existing files are correctly applied at the new
> location).
> 
> I checked the open OGM PRs and the only critical ones seem to be the ones
> for OGM-208 [2], [3]. The others mostly say "do not include"; OGM-293 needs
> to be reworked anyways [4]. Besides that there are two very old PRs (Redis
> and Voldemort support, [5], [6]) which I'm unsure about. Are these even
> still up to date?
> 
> Based on that, my suggestion is to execute the renaming once OGM-208 has
> been resolved. Any thoughts?
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/OGM-248
> [2] https://github.com/hibernate/hibernate-ogm/pull/211
> [3] https://github.com/hibernate/hibernate-ogm/pull/217
> [4] https://github.com/hibernate/hibernate-ogm/pull/218
> [5] https://github.com/hibernate/hibernate-ogm/pull/98
> [6] https://github.com/hibernate/hibernate-ogm/pull/47
> ___
> 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] hiberate-commons-annotations and locating annotations

[Emmanuel Bernard]

On Thu 2013-08-29 14:22, Steve Ebersole wrote:
> Given an XProperty, is there a way to ask for annotations which are 
> defined only locally on that declared property (not on any super classes)?

I believe that is what XProperty will give you.
The list of XProperty of a given XClass is computed from
Class.getDeclaredMethod, so it does not look for superclass methods.

Could it be that @Convert is marked @Inherited?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hiberate-commons-annotations and locating annotations

[Emmanuel Bernard]

On Thu 2013-08-29 16:16, Steve Ebersole wrote:
> Ok, so given the initial Super/Sub setup, what we get in
> SimpleValueBinder#setType is this:
> 
> 1) The XProperty passed in is defined as follows:
> a) It is a JavaXProperty speciffically
> b) Its 'annotatedElement' attribute (not exposed) is the
> java.lang.reflect.Field for the Super#it field.
> c) Interestingly, the SimpleValueBinder#xproperty is the same exact
> instance.  Can these ever be different?

I seem to recall some case around embeddable, id or mapid where a surrogate
XProperty might be needed.

> 
> 2) The 'declaringClassName' passed in to SimpleValueBinder#setType
> is Sub. So maybe we can leverage that.  But
> org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
> (the main caller of this method) has explicit handle for null-ness
> so that makes me nervous.
> 
> Given the differing rules for resolving converter to use for basic
> types, collections and composites and the fact that these
> distinctions are already handled in the PropertyHolder hierarchy, I
> think it would be better to handle those distinctions there.  Either
> adding a separate method to inject the converter to use (making sure
> it is called before setType, ugh) or changing the signature of
> setType to accept the converter to use.
> PropertyBinder#makePropertyAndValue would then use
> PropertyHolder#resolveAttributeConverter to pass what it needs to
> pass.
> 
> WDYT?

Yes that makes sense to consolidate this logic in PropertyHolder. But I
have to admit I failed to find an elegant algorithm and data structure
to resolve the convert use cases you have described. All involved some
back reading of annotations etc :(

BTW is it possible to have the illegal case by mean of mixing XML and
annotation. ie you have the @Convert on the property and the disable
facility at the class level in XML. Does the same rule apply?
Because for sure the XML and the annotation are treated equally by
commons annotation.

> 
> 
> 
> On Thu 29 Aug 2013 03:06:37 PM CDT, Gunnar Morling wrote:
> >2013/8/29 Emmanuel Bernard  ><mailto:emman...@hibernate.org>>
> >
> >On Thu 2013-08-29 14:22, Steve Ebersole wrote:
> >> Given an XProperty, is there a way to ask for annotations which are
> >> defined only locally on that declared property (not on any super
> >classes)?
> >
> >I believe that is what XProperty will give you.
> >The list of XProperty of a given XClass is computed from
> >Class.getDeclaredMethod, so it does not look for superclass methods.
> >
> >Could it be that @Convert is marked @Inherited?
> >
> >
> >@Inherited applies to annotations on classes only, it has no effect
> >for annotations on properties.
> >
> >___
> >hibernate-dev mailing list
> >hibernate-dev@lists.jboss.org <mailto: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] hiberate-commons-annotations and locating annotations

[Emmanuel Bernard]

On Fri 2013-08-30  6:27, Steve Ebersole wrote:
> 
> On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
> >>
> >>
> >>2) The 'declaringClassName' passed in to SimpleValueBinder#setType
> >>is Sub. So maybe we can leverage that. But
> >>org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
> >>(the main caller of this method) has explicit handle for null-ness
> >>so that makes me nervous.
> >>
> >>Given the differing rules for resolving converter to use for basic
> >>types, collections and composites and the fact that these
> >>distinctions are already handled in the PropertyHolder hierarchy, I
> >>think it would be better to handle those distinctions there. Either
> >>adding a separate method to inject the converter to use (making sure
> >>it is called before setType, ugh) or changing the signature of
> >>setType to accept the converter to use.
> >>PropertyBinder#makePropertyAndValue would then use
> >>PropertyHolder#resolveAttributeConverter to pass what it needs to
> >>pass.
> >>
> >>WDYT?
> >
> >
> >Yes that makes sense to consolidate this logic in PropertyHolder. But I
> >have to admit I failed to find an elegant algorithm and data structure
> >to resolve the convert use cases you have described. All involved some
> >back reading of annotations etc :(
> 
> Depends what you mean "back-reading".  I planned on sifting through
> the annotations as "resolve" is called.
> 
> >
> >BTW is it possible to have the illegal case by mean of mixing XML and
> >annotation. ie you have the @Convert on the property and the disable
> >facility at the class level in XML. Does the same rule apply?
> >Because for sure the XML and the annotation are treated equally by
> >commons annotation.
> 
> The convert subelement is additive to any Convert or Converts
> annotations on the entity. It
> overrides any Convert annotation for the same attribute name. If a
> convert subelement is present,
> and attributes or subelements of that convert subelement are not
> explicitly specified, their default
> values are applied
> 
> 
> My reading of that on your use-case is that we really should apply
> the XML-defined converter.  But hiberate-commons-annotations simply
> does not give us the information needed to be able to do that
> properly.

You can do that, you would code the logic in JPAOverriddenAnnotationReader in 
ORM Core.
Check getAttributeOverrides / mergeAttributeOverrides as an example of
how to read Java annotation, the XML "annotations" and merge the two as
you please.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hiberate-commons-annotations and locating annotations

[Emmanuel Bernard]

Yes I get that but JPAOverriddenAnnotationReader is only about reading
the XML and converting it into annotations.

I understand that implementing the rules based on the annotations is
more complex than annotation override.

On Fri 2013-08-30  8:44, Steve Ebersole wrote:
> Its not that easy.  This is not as simple as AttributeOverride.  The
> rules here are much more complex (or convoluted, depending on your
> perspective).  An AttributeOverride always overrides.  The is just
> not the case here with converters.  Plus how AttributeOverride works
> does not need to vary from one use case to another (basics,
> composites, plurals).
> 
> 
> On Fri 30 Aug 2013 07:47:36 AM CDT, Emmanuel Bernard wrote:
> >On Fri 2013-08-30  6:27, Steve Ebersole wrote:
> >>
> >>On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
> >>>>
> >>>>
> >>>>2) The 'declaringClassName' passed in to SimpleValueBinder#setType
> >>>>is Sub. So maybe we can leverage that. But
> >>>>org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
> >>>>(the main caller of this method) has explicit handle for null-ness
> >>>>so that makes me nervous.
> >>>>
> >>>>Given the differing rules for resolving converter to use for basic
> >>>>types, collections and composites and the fact that these
> >>>>distinctions are already handled in the PropertyHolder hierarchy, I
> >>>>think it would be better to handle those distinctions there. Either
> >>>>adding a separate method to inject the converter to use (making sure
> >>>>it is called before setType, ugh) or changing the signature of
> >>>>setType to accept the converter to use.
> >>>>PropertyBinder#makePropertyAndValue would then use
> >>>>PropertyHolder#resolveAttributeConverter to pass what it needs to
> >>>>pass.
> >>>>
> >>>>WDYT?
> >>>
> >>>
> >>>Yes that makes sense to consolidate this logic in PropertyHolder. But I
> >>>have to admit I failed to find an elegant algorithm and data structure
> >>>to resolve the convert use cases you have described. All involved some
> >>>back reading of annotations etc :(
> >>
> >>Depends what you mean "back-reading".  I planned on sifting through
> >>the annotations as "resolve" is called.
> >>
> >>>
> >>>BTW is it possible to have the illegal case by mean of mixing XML and
> >>>annotation. ie you have the @Convert on the property and the disable
> >>>facility at the class level in XML. Does the same rule apply?
> >>>Because for sure the XML and the annotation are treated equally by
> >>>commons annotation.
> >>
> >>The convert subelement is additive to any Convert or Converts
> >>annotations on the entity. It
> >>overrides any Convert annotation for the same attribute name. If a
> >>convert subelement is present,
> >>and attributes or subelements of that convert subelement are not
> >>explicitly specified, their default
> >>values are applied
> >>
> >>
> >>My reading of that on your use-case is that we really should apply
> >>the XML-defined converter.  But hiberate-commons-annotations simply
> >>does not give us the information needed to be able to do that
> >>properly.
> >
> >You can do that, you would code the logic in JPAOverriddenAnnotationReader 
> >in ORM Core.
> >Check getAttributeOverrides / mergeAttributeOverrides as an example of
> >how to read Java annotation, the XML "annotations" and merge the two as
> >you please.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Required improvements for Infinispan's query engine

[Emmanuel Bernard]

Adrian found a few problematic limitations in Hibernate Search during
its integration of the HQL query parser and the Hibernate Search back
end.

Composite bridge::
https://hibernate.atlassian.net/browse/HSEARCH-1397

Injection of services into a FieldBridge::
https://hibernate.atlassian.net/browse/HSEARCH-1396

These two are important for Infinispan 6 and should be give priority.
I think they can be added in 4.4 without too much effort.

Thoughts?

Otherwise, support for mapping non Java object structures is something
we should do in Hibernate Search. For 5?
Is there a JIRA for it?

Emmanuel

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

Re: [hibernate-dev] [Validator] Applying constraints to property objects

[Emmanuel Bernard]

Something like c makes sense.
It similar to the notion of converter in JPA.

But why not the following style of interfaces

interface Convert {
To convert(From);
}


On Tue 2013-09-03 15:58, Gunnar Morling wrote:
> Hi,
> 
> Yesterday George Gastaldi from the Forge team approached me regarding the
> application of constraints to "wrapped" properties. Their situation is the
> following:
> 
> ...
> @Size(min=3, max=10)
> UIInput name;
> ...
> 
> Here, UInput is some kind of UI component, wrapping the actual property
> value. As is, validation of this property will fail since there is no
> validator for applying @Size to UIInput (only for String).
> 
> A similar use case exists in JavaFX where one might want to apply
> constraints to the FX *Property types:
> 
> ...
> @Min(5)
> IntegerProperty count = new SimpleIntegerProperty(4);
> ...
> 
> Again, validation will fail out of the box, as no validator for applying
> @Min to IntegerProperty exists (but for int/Integer).
> 
> How could this be solved? The following alternatives came to my mind:
> 
> a) Create and register validators for these wrapper types, e.g.
> ConstraintValidator etc.
> 
> Pro: Works with the existing APIs without modification
> Con: Lots of code to write, either duplicating code or delegating to
> (internal) implementation types; doesn't automatically benefit from new
> built-in validators
> 
> b) Apply constraints to getters instead of fields:
> 
> IntegerProperty count = new SimpleIntegerProperty(4);
> 
> @Min(5)
> int getCount() {
> return count.getValue();
> }
> 
> Pro: Works with the existing APIs without modification; benefits from any
> newly added built-in validators
> Con: There may be cases where there is no such getter, e.g. for parameter
> validation
> 
> c) Provide an SPI which allows to plug in a custom "value processor"
> implementation, retrieving the wrapped object and its "declared" type:
> 
> public interface ValidationValueProcessor {
> Object getValidatedValue(Object source);
> Type getDeclaredType(Type sourceType);
> }
> 
> For the original example, the methods would return the name value and
> String.class, respectively.
> 
> Note that validator resolution is done using the static type of a property,
> so I think the original example above should be supported, but the
> following should not as no validator for @Size/Object exists:
> 
> @Size(min=3, max=10)
> UIInput name;
> 
> Pro: Benefits from any newly added built-in validators, allows directly
> annotating "wrapped" properties, requires no implementation by the user
> besides the ValidationValueProcessor
> Con: new HV-specific (at least for the time being) SPI
> 
> I think a) creates prohibitively high efforts for the user/integrator, b)
> lacks support for method constraints, so I think c) should be implemented,
> possibly making this a spec SPI later on.
> 
> Does anyone have other preferences or alternatives? If you also think c)
> makes most sense, do you have a good/better idea for the interface and
> method names?
> 
> 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] Fwd: Re: [Validator] Applying constraints to property objects

[Emmanuel Bernard]

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

Re: [hibernate-dev] hiberate-commons-annotations and locating annotations

[Emmanuel Bernard]

On Tue 2013-09-03 17:22, Steve Ebersole wrote:
> 2.a) It seems like there are times when
> org.hibernate.cfg.AbstractPropertyHolder#parent would be useful for
> what I need to do.  But there appears to be times when this is null.
> For entity mappings (ClassPropertyHolder) thats fine.  But for the
> others, that would be problematic.  Going back to the
> Person#homeAddress example, I'd really need the
> ComponentPropertyHolder for Person#homeAddress to register the
> converts with ClassPropertyHolder under the "homeAddress"
> base key ("homeAddress.city" for example).  Is there a time here
> where AbstractPropertyHolder#parent would be null for
> ComponentPropertyHolder/CollectionPropertyHolder?

I looked around the code base and the only case I could find is for
ClassPropertyHolder whose parent is indeed null.

> 2.b) Is this AbstractPropertyHolder#parent the best way you see to
> handle path-based converts?  Or do you see a better option?
> 

Yes I still think it's the best aproach and frankly I don't quite see
alternatives.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Validator] Applying constraints to property objects

[Emmanuel Bernard]

On Wed 2013-09-04  8:27, Gunnar Morling wrote:
> 2013/9/3 Emmanuel Bernard 
> 
> > Something like c makes sense.
> >
> 
> Ok.
> 
> 
> > It similar to the notion of converter in JPA.
> >
> > But why not the following style of interfaces
> >
> > interface Convert {
> > To convert(From);
> > }
> >
> 
> Yes, thinking more about it, it probably makes sense to support multiple
> converters, e.g. in case someone works with UIInput and *Property in the
> same application. Then the "From" parameter makes sense to avoid casts
> within the converter implementation. Need to experiment with it a bit.

More than just the cast in the impl, its a way to statically know that
you have a converter that takes From and only From, so you can restrict
the list of converters to consider to 0 or 1 all the time (assuming we
don't support multiple converters of the same From.

> 
> Regarding the name, I find "Converter" a bit too generic, in particular
> since it needs not only to convert the actual property value but also the
> static type so you can reject this (because @Size can't be applied to
> Object):

Not sure I follow, before the core HV work, it converts a property or
class from From to To and from there you are good to go.

Are you saying that if From = UIInput we would not be able to
separate it from UIInput statically? I *think* we can, just like
we do for collections in JPA.

> 
> @Size(min=3, max=10)
> UIInput name;
> 
> 
> On Tue 2013-09-03 15:58, Gunnar Morling wrote:
> > > Hi,
> > >
> > > Yesterday George Gastaldi from the Forge team approached me regarding the
> > > application of constraints to "wrapped" properties. Their situation is
> > the
> > > following:
> > >
> > > ...
> > > @Size(min=3, max=10)
> > > UIInput name;
> > > ...
> > >
> > > Here, UInput is some kind of UI component, wrapping the actual property
> > > value. As is, validation of this property will fail since there is no
> > > validator for applying @Size to UIInput (only for String).
> > >
> > > A similar use case exists in JavaFX where one might want to apply
> > > constraints to the FX *Property types:
> > >
> > > ...
> > > @Min(5)
> > > IntegerProperty count = new SimpleIntegerProperty(4);
> > > ...
> > >
> > > Again, validation will fail out of the box, as no validator for applying
> > > @Min to IntegerProperty exists (but for int/Integer).
> > >
> > > How could this be solved? The following alternatives came to my mind:
> > >
> > > a) Create and register validators for these wrapper types, e.g.
> > > ConstraintValidator etc.
> > >
> > > Pro: Works with the existing APIs without modification
> > > Con: Lots of code to write, either duplicating code or delegating to
> > > (internal) implementation types; doesn't automatically benefit from new
> > > built-in validators
> > >
> > > b) Apply constraints to getters instead of fields:
> > >
> > > IntegerProperty count = new SimpleIntegerProperty(4);
> > >
> > > @Min(5)
> > > int getCount() {
> > > return count.getValue();
> > > }
> > >
> > > Pro: Works with the existing APIs without modification; benefits from any
> > > newly added built-in validators
> > > Con: There may be cases where there is no such getter, e.g. for parameter
> > > validation
> > >
> > > c) Provide an SPI which allows to plug in a custom "value processor"
> > > implementation, retrieving the wrapped object and its "declared" type:
> > >
> > > public interface ValidationValueProcessor {
> > > Object getValidatedValue(Object source);
> > > Type getDeclaredType(Type sourceType);
> > > }
> > >
> > > For the original example, the methods would return the name value and
> > > String.class, respectively.
> > >
> > > Note that validator resolution is done using the static type of a
> > property,
> > > so I think the original example above should be supported, but the
> > > following should not as no validator for @Size/Object exists:
> > >
> > > @Size(min=3, max=10)
> > > UIInput name;
> > >
> > > Pro: Benefits from any newly added built-in validators, allows directly
> > > annotating "wrapped"

Re: [hibernate-dev] [Validator] Applying constraints to property objects

[Emmanuel Bernard]

On Wed 2013-09-04  9:26, Gunnar Morling wrote:
> 2013/9/4 Emmanuel Bernard 
> 
> > On Wed 2013-09-04  8:27, Gunnar Morling wrote:
> > > 2013/9/3 Emmanuel Bernard 
> > >
> > > > Something like c makes sense.
> > > >
> > >
> > > Ok.
> > >
> > >
> > > > It similar to the notion of converter in JPA.
> > > >
> > > > But why not the following style of interfaces
> > > >
> > > > interface Convert {
> > > > To convert(From);
> > > > }
> > > >
> > >
> > > Yes, thinking more about it, it probably makes sense to support multiple
> > > converters, e.g. in case someone works with UIInput and *Property in the
> > > same application. Then the "From" parameter makes sense to avoid casts
> > > within the converter implementation. Need to experiment with it a bit.
> >
> > More than just the cast in the impl, its a way to statically know that
> > you have a converter that takes From and only From, so you can restrict
> > the list of converters to consider to 0 or 1 all the time (assuming we
> > don't support multiple converters of the same From.
> >
> > >
> > > Regarding the name, I find "Converter" a bit too generic, in particular
> > > since it needs not only to convert the actual property value but also the
> > > static type so you can reject this (because @Size can't be applied to
> > > Object):
> >
> > Not sure I follow, before the core HV work, it converts a property or
> > class from From to To and from there you are good to go.
> >
> > Are you saying that if From = UIInput we would not be able to
> > separate it from UIInput statically? I *think* we can, just like
> > we do for collections in JPA.
> >
> 
> No, I'm not saying that. I also think we can separate that.
> 
> There is two steps involved:
> 
> * Resolve the correct validator for the validated element, using its
> declared (static) type; E.g. in the following case we'd need to find the
> validator for @Size/String:
> 
> @Size(min=3)
> UIInput name;
> 
> While in this case we'd have to throw an exception since there is no
> validator for @Size/Object:
> 
> @Size(min=3)
> UIInput name;
> 
> For this step I envisioned the method "Type getDeclaredType(Type
> sourceType)" (better name to be found, unwrapDeclaredType()?), which would
> return the "real" type to consider for validator resolution (here, String
> or Object, respectively).
> 
> * If we have found the right validator, use it to validate the given value.
> For this step I envisioned the getValidatedValue() method which obtains the
> value from the given wrapped property before passing it to the validator.

What I am arguing then is that the getDeclaredType method is unnecessary if
the converter class captures the type already via the From parameterized
type.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hiberate-commons-annotations and locating annotations

[Emmanuel Bernard]

;> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Wed 04 Sep 2013 02:44:40 PM CDT, Steve Ebersole wrote:
>>>>>>> 
>>>>>>> I am still a bit confused on how to apply the normalization to make
>>>>>>> sure it happens in the proper order.
>>>>>>> 
>>>>>>> Let's look at:
>>>>>>> 
>>>>>>> @Entity
>>>>>>> class Person {
>>>>>>> ...
>>>>>>> @Embedded
>>>>>>> @Convert( attributeName="city", converter=Converter2.class )
>>>>>>> public Address homeAddress;
>>>>>>> }
>>>>>>> 
>>>>>>> @Embeddable
>>>>>>> class Address {
>>>>>>> ...
>>>>>>> @Convert( converter=Converter1.class )
>>>>>>> public String city;
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> So here, the Converter2 class ought to be the one applied to
>>>>>>> "homeAddress.city" path.
>>>>>>> 
>>>>>>> Now granted there are a few different ways to skin this cat, but the
>>>>>>> plan I had was to normalize these all on the root of the path. So
>>>>>>> here, both of these conversions would get stored on
>>>>>>> ClassPropertyHolder under the "homeAddress.city" path. When I
>>>>>>> go to build the SimpleValue for Person.homeAddress.city, I'd ask the
>>>>>>> CompositePropertyHolder for Person.homeAddress to resolve the explicit
>>>>>>> (non-autoApply) conversion for its city attribute (the simple value).
>>>>>>> The trouble I have though is applying the conversions in the proper
>>>>>>> order. For example, here, I'd want to apply the conversions defined
>>>>>>> directly on the Embeddable first (the Embeddable conversions should
>>>>>>> always act as the baseline), then the conversions at its Embedded
>>>>>>> point (via XML or annotations).
>>>>>>> 
>>>>>>> One idea was to hook into org.hibernate.cfg.PropertyHolder#addProperty
>>>>>>> in terms of normalizing the paths. I am just not sure of the timing
>>>>>>> between these PropertyHolder#addProperty (and how populated the passed
>>>>>>> Property objects are at that point) and the calls to
>>>>>>> SimpleValueBinder/PropertyBinder.
>>>>>>> 
>>>>>>> Interestingly, I still am not sure we have enough here to report an
>>>>>>> error in cases like:
>>>>>>> 
>>>>>>> @Entity
>>>>>>> @Convert( attributeName="homeAddress.city", converter=Converter3.class )
>>>>>>> class Person {
>>>>>>> ...
>>>>>>> @Embedded
>>>>>>> @Convert( attributeName="city", converter=Converter2.class )
>>>>>>> public Address homeAddress;
>>>>>>> }
>>>>>>> 
>>>>>>> Unless we somehow kept "proximity info" or "location info" about the
>>>>>>> conversion in PropertyHolder.
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed 04 Sep 2013 01:27:21 AM CDT, Emmanuel Bernard wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue 2013-09-03 17:22, Steve Ebersole wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2.a) It seems like there are times when
>>>>>>>>> org.hibernate.cfg.AbstractPropertyHolder#parent would be useful for
>>>>>>>>> what I need to do. But there appears to be times when this is null.
>>>>>>>>> For entity mappings (ClassPropertyHolder) thats fine. But for the
>>>>>>>>> others, that would be problematic. Going back to the
>>>>>>>>> Person#homeAddress example, I'd really need the
>>>>>>>>> ComponentPropertyHolder for Person#homeAddress to register the
>>>>>>>>> converts with ClassPropertyHolder under the "homeAddress"
>>>>>>>>> base key ("homeAddress.city" for example). Is there a time here
>>>>>>>>> where AbstractPropertyHolder#parent would be null for
>>>>>>>>> ComponentPropertyHolder/CollectionPropertyHolder?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I looked around the code base and the only case I could find is for
>>>>>>>> ClassPropertyHolder whose parent is indeed null.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2.b) Is this AbstractPropertyHolder#parent the best way you see to
>>>>>>>>> handle path-based converts? Or do you see a better option?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Yes I still think it's the best aproach and frankly I don't quite see
>>>>>>>> alternatives.
>>>>>> ___
>>>>>> 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] Using two level queries to fight stop word disease

[Emmanuel Bernard]

I don't even know if that's actually useful :) But yes if it is, some DSL
makes sense.

On Fri 2013-09-06 18:31, Hardy Ferentschik wrote:
> Interesting idea. We should at least have a Jira issue for that. Do you think 
> about some DSL support for that?
> 
> --Hardy
> 
> On 26 Jan 2013, at 5:26 PM, Emmanuel Bernard  wrote:
> 
> > The elasticsearch guys have done something quite smart
> > 
> > http://www.elasticsearch.org/blog/stop-stopping-stop-words-a-look-at-common-terms-query/
> > 
> > Basically combine a classic query with a query with the stop words. And 
> > stop words are defined by their frequency. 
> > 
> > Anyone want to implement something similar and play with it to see of 
> > that's useful in practice ?
> > 
> > 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] [HV] Extending ParameterNameProvider contract for other element types

[Emmanuel Bernard]

It seems that what this user really needs is a way to convert the 
Set into another format entirely, JSON in this case. I 
wonder if we could find a more generic approach than just the ability to change 
properties names. 

On 19 sept. 2013, at 09:05, Gunnar Morling  wrote:

> Hi,
> 
> On SO [1], a user asked whether it's possible to report custom names for
> property constraint violations, e.g. "nm" as retrieved from the annotation
> in this case:
> 
>@JsonProperty("nm")
>@NotNull
>final public String name;
> 
> At the moment that's not possible with HV, but one might think about a
> contract similar to ParameterNameProvider which returns the reported names
> for properties (or even custom names to be used instead of the constants
> "" and "").
> 
> It's the first time I came across this requirement but adding support for
> this should not be too complex and it might be helpful to some. Any
> thoughts?
> 
> --Gunnar
> 
> [1]
> http://stackoverflow.com/questions/18878868/hibernate-validator-and-jackson-using-the-jsonproperty-value-as-the-constraint
> ___
> 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] Hibernate ORM and JDK 6

[Emmanuel Bernard]

I am still stuck on that one. I cannot import Hibernate ORM in IntelliJ IDEA :(

On 17 mai 2013, at 03:28, Emmanuel Bernard wrote:

> yes the projects themselves can use JDK 7.
> 
> On Fri 2013-05-17 11:59, Gunnar Morling wrote:
>> Have you registered a JDK 7 under "Platform Settings" -> "SDKs"?
>> 
>> 
>> 2013/5/17 Sanne Grinovero 
>> 
>>> ORM requires JDK7 to build, while it still targets Java6 for users.
>>> On 17 May 2013 10:26, "Emmanuel Bernard"  wrote:
>>> 
>>>> I tried to get ORM imported in IntelliJ IDEA and it fails with a
>>>> Unsupported major.minor version 51.0.  In Mac OS IntelliJ boots with JDK
>>>> 1.6 AFAIK and it seems the tools (like gradle) inherit this.
>>>> 
>>>> Any of the Mac guys found an acceptable solution to import the Gradle
>>>> project in IntelliJ?
>>>>> From what
>>>> 
>>>> 
>>> http://stackoverflow.com/questions/13019199/how-do-i-run-idea-intellij-on-mac-os-x-with-jdk-7
>>>> says, it's sort of messy to force JDK 7.
>>>> 
>>>> 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

Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

[Emmanuel Bernard]

But then the JSON binding technology should be responsible for the
property anme conversion too, right? After all that is the layer that
does this change.

On Thu 2013-09-19 10:35, Gunnar Morling wrote:
> I also think that the conversion of the ConstraintViolation(s) into another
> format is more in the responsibility of the integrating technology.
> 
> Taking JAX-RS/Resteasy as example, it will transparently convert any
> constraint violation objects into an equivalent XML or JSON response.
> Provided we return the wished property name in the reported violation,
> Resteasy's conversion would take over from there.
> 
> 
> 2013/9/19 Hardy Ferentschik 
> 
> >
> > On 19 Jan 2013, at 9:44 AM, Emmanuel Bernard 
> > wrote:
> >
> > > It seems that what this user really needs is a way to convert the
> > Set into another format entirely, JSON in this case. I
> > wonder if we could find a more generic approach than just the ability to
> > change properties names.
> >
> > Well, there are really two problems. First the creation of the JSON format
> > and then the property name "conversion". I think they need to be addressed
> > separately. Even if we had/offered something to convert the constraint
> > violations, we still
> > would report the actual property name.
> >
> > In the described use case I would write the conversion code myself. The
> > constraint violation contains all the information needed to create the JSON
> > format and do the name conversion. It should not be hard to write.
> >
> > --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] [OGM] Hibernate OGM @ Devoxx

[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

Re: [hibernate-dev] Should we deprecate @Similarity

[Emmanuel Bernard]

Yes that was a mistake. It was done as you say to make things simpler
for the user but it has created headaches for us since then.

On Thu 2013-09-19 16:15, Sanne Grinovero wrote:
> Discussing about some hibernate-search-engine complexities with Hardy
> on IRC, we came to the agreement that the way @Similarity behaves
> today was a mistake, so we're proposing to deprecate it in 4.4.
> 
> Reasoning follows.
> 
> There is a strong requirement in Lucene that all operations on the
> same index need to use the same Similarity implementation. We infer
> the org.apache.lucene.search.Similarity to be used on a specific index
> from either:
> 
> - the similarity property from the configuration file, which is
> positioned on an index name
> - the @Similarity annotation positioned on an indexed entity
> 
> The trouble is about all these options needing to be consistent; first
> problem is there isn't a precedence rule: if one of them is not
> specified, we assume the user is using the other way to configure
> things. But also different entities might be sharing the same index,
> which leads to needing to verify that at least the user isn't
> specifying some contradictory option.
> 
> This all gets more confusing when you introduce the notion of
> dynamically added new entities (a feature used by Infinispan) and/or
> Dynamic Sharding, in which the properties of some indexes might
> conflict with the specified @Similarity, but we might notice this only
> at runtime rather than at bootstrap. Failing to load a class at this
> point is far more annoying to the users than to fail the health-check
> at bootstrap time.
> 
> So the proposal:
> drop the @Similarity annotation and use properties exclusively.
> Properties are more suited for this as they are set on a per-index
> base, which is what matters in this case.
> 
> Downside:
> I guess lots of people where using a single index per type, and for
> those there was no danger to simply specify a @Similarity. We lose
> this straight-forward way of things, but I'd argue that if you're in
> the business of specifying a custom Similarity, you're a very advanced
> user and wouldn't mind setting a one-liner in your configuration file.
> 
> Do we agree?
> 
> 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] [Search] Dynamic Sharding the second

[Emmanuel Bernard]

Turning the problem upside down, I wonder if IndexShardingStrategy
should be deprecated and have SharIdentifierProvider as the API a user
would implement. It makes for simpler things. What would we lose feature
wise?

Emmanuel

On Fri 2013-09-20 17:30, Hardy Ferentschik wrote:
> Hi,
> 
> here comes a follow up on my previous email regarding configuration of 
> dynamic sharding.
> 
> Now I would like to get some feedback on ShardIdentifierProvider. This 
> interface was added for dynamic sharding on
> top of DynamicShardingStrategy. Gunnar and I had a discussion around it today 
> [1] and we came to the conclusion that
> this interface is actually not needed and just adds confusion in the API. 
> 
> Really ShardIdentifierProvider is a IndexShardingStrategy in disguise. Add 
> 'forAddtion' and 'forDeletion' to the two 'getShardIdentifier' methods 
> and you have (almost) an IndexShardingStrategy. The problem seems to be, that 
> in order to implement dynamic sharding the
> IndexManagerHolder and EntityIndexBinding are needed. 
> IndexShardingStrategy#initialize does not provide access to these objects 
> which maybe
> led to the current design.
> 
> In DynamicShardingStrategy this is taken care of by passing 
> IndexManagerHolder and EntityIndexBinding as part of the constructor 
> arguments. 
> Otherwise DynamicShardingStrategy is just a very thin wrapper delegating to 
> the ShardIdentifierProvider.
> 
> If the current IndexShardingStrategy#initialize method would get passed the 
> required information for dynamic sharding, there would be no need 
> for an additional interface like ShardIdentifierProvider. Dynamic sharding 
> could be implemented with the existing extension points and implementations
> would fit better into the current pattern of providing custom 
> implementations. 
> 
> What we could do is to make DynamicShardingStrategy an interface extending 
> IndexShardingStrategy and adding a second initialise contract
> of sorts. This would keep backwards compatibility, but also allow for dynamic 
> sharding by users implementing DynamicShardingStrategy.
> 
> At the downside the user would have to write a bit more code, but I think 
> that's acceptable given the more consistent approach towards sharding. 
> 
> Thoughts?
> 
> --Hardy
> 
> P.S. In case you guys think that we really should hold on to 
> ShardIdentifierProvider, I would at least suggest to either rename 
> the two 'getShardIdentifier' methods adding 'forAddition' and 'forDeletion' 
> or even collapse the two into a single method (not sure
> whether this is easily possible)
> 
> 
> [1] 
> http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2013/%23hibernate-dev.2013-09-20.log.html
> ___
> 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] Hibernate OGM @ Devoxx

[Emmanuel Bernard]

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

Re: [hibernate-dev] [Search] Dynamic Sharding the second

[Emmanuel Bernard]

On Wed 2013-10-02 15:19, Hardy Ferentschik wrote:
> 
> On 2 Jan 2013, at 3:06 PM, Emmanuel Bernard  wrote:
> 
> > Turning the problem upside down, I wonder if IndexShardingStrategy
> > should be deprecated and have SharIdentifierProvider as the API a user
> > would implement. It makes for simpler things. What would we lose feature
> > wise?
> 
> That is exactly what we have done and we don't think anything is lost :-)

I should take more time offline then it seems. Fine by me ;)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Dynamic sharding configuration

[Emmanuel Bernard]

On Tue 2013-09-24 10:51, Hardy Ferentschik wrote:
> String[] getShardIdentifiers(Class entity, Serializable id, String 
> idInString);
> 
> all together. Here is my reasoning. AFAIU, the method is there for the 
> deletion of
> documents. In this case we don't have the Lucene document nor the entity and 
> we need
> to know in which shard the document to delete is. The assumptions behind this 
> method is
> that somehow given the type and id I am able to provide this shard or a 
> subset of the shards.
> I doubt, however, that this is practically ever possible. In the end most 
> implementations will
> have to just delegate to getAllShardIdentifiers() anyways. Take the language 
> code example or
> any other case where I shard depending on a given property of the entity. In 
> this case I will
> never be able to make any use of #getShardIdentifiers(Class , Serializable 
> , String)
> 
> In fact the same arguments probably apply to getShardIdentifiersForQuery. 
> What is the use case 
> for that really? In which use case can the set of targeted shards be limited 
> based on knowing the
> type of filers we apply? 
> 
> So why not remove #getShardIdentifiers and #getShardIdentifiersForQuery and 
> start of with a much
> simpler interface. We can indeed mark it as experimental and if the need 
> arises (based on a true use case)
> think about optimisations. 
> 
> The more I think about it, the more I like this more minimalistic approach.

When ISStrategy was introduced the idea was that somehow, the
implementor could receive information from the runtime with the right
(set of) shard(s). For example, in a multi-tenant app and I *know*
what shard the currently logged user is allowed to temper with. I will always 
filter by
that shard even for deletion.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Dynamic sharding configuration

[Emmanuel Bernard]

What does Iterable give you over String[]?

On Mon 2013-09-23 23:04, Sanne Grinovero wrote:
> Correct me if I'm wrong, but trying to synthesize this discussion I
> think that we're fundamentally agreeing that dynamic sharding is a
> "better replacement" for static sharding.
> Still, let's keep in mind that this needs to be a backwards compatible
> patch, so we're not looking for something disruptive of the current
> static sharding feature. If we end up agreeing that the better API
> needs disruption, we should still make an incremental change available
> in this version - as experimental - so that people can play with it,
> then we're free to reset the API as we wish in 5.0 but at least
> including the newly acquired experience.
> 
> We then had some brainstorming on IRC which concluded that it would be
> probably more user friendly to have the __Strategy to:
>  a) not return arrays but simple collections
>  b) avoid the confusion on the two too similar methods on the proposal
> for ShardIdentifierProvider (next paragraph)
>  c) not apply the sharding logic based on the Document (fields) but on
> the entity (the user type triggering the index event)
> 
> As a reminder, the proposal for ShardIdentifierProvider is - omitting
> initialize - :
> 
> /**
>  * Returns the shard identifier upon addition.
>  */
> String getShardIdentifier(Class entity, Serializable id, String
> idInString, Document document);
> 
> /**
>  * Returns the set of shard identifiers upon deletion.
>  */
> String[] getShardIdentifiers(Class entity, Serializable id,
> String idInString);
> 
> /**
>  * Returns the set of shard identifiers for a query.
>  */
> String[] getShardIdentifiersForQuery(FullTextFilterImplementor[]
> fullTextFilters);
> 
> /**
>  * Returns the list of all known shard identifiers.
>  * The list can vary between calls.
>  */
> String[] getAllShardIdentifiers();
> 
> #a
> Ok we can consider that but let's see how the code turns out.
> Iterable perhaps?
> 
> #b
> we explored converging the two methods into the essential one:
> 
>String getShardIdentifier(Class entity, Serializable id, String
> idInString);
> 
> but that seems very poor in terms of flexibility, it doesn't even
> allow access to the basic properties of the indexed entity. So that
> degenerated in the proposal #c, but before moving to #c I'd venture
> that these methods aren't that bad, they just need good documentation.
> Also, even if we move the focus from the Document to the Entity, we
> still don't have the fully loaded entity during a delete operation, so
> we would still need the second method returning multiple indexes.
> 
> #c
> drawbacks first:
>  = to expose the entity directly has probably some risk (the user
> making changes to it), but that's no different to what the user can
> already do from a FieldBridge / ClassBridge.
>  = won't be able to consider the output of FieldBridge / ClassBridge
> instances as you won't have the Document
>  = for deletion you still don't have the entity
> 
> We could list some conceptually interesting advantages here, but I'd
> like to shut down this feature for the time being because it's
> significantly different than the goal of providing Dynamic Sharding as
> a feature. I'm not saying that it doesn't have merit: its probably
> worth exploring for 5+ but it rather seems like an _additional_ level
> of sharding that we might want to add in future as an alternative to
> the one focusing on the Document approach.
> 
> So assuming that sounds reasonable, and that we're on the same page
> for a#, let's focus on b#: the duality of the methods for add/remove
> during sharding.
> My position is that it worked well so far on static sharding, and that
> the proposal is quite consistent with it so wouldn't be much of a pain
> for people to adapt the new model. Let's try polishing the method
> names (and use your imagination for a well written javadoc):
> 
> String getShardIdFromDocument(Class entity, Serializable id,
> String idInString, Document document);
> 
> Iterable getShardIdsFromId(Class entity, Serializable
> id, String idInString);
> 
> or maybe to highlight what's fundamentally different:
> 
> String getShardIdFromContext(Class entity, Serializable id,
> String idInString, Document document);
> 
> Iterable getShardIdsFromReducedContext(Class entity,
> Serializable id, String idInString);
> 
> 
> I especially like the javadoc! well done.
> WFYT?
> 
> 
> Bonus dilemma: should we stay away from String and define some
> "IndexIdentifier" interface ? Note that while design wise it might
> look good, this is on a very hot path so while I'd like proposing such
> an SPI it would be great if we could find a way in which this would
> not require to allocate objects at runtime just to replace a mere
> string with a safer type.
> 
> Sanne
> 
> 
> 
> On 23 September 2013 13:58, Hardy Ferentschik  wrote:
> >
> > On 23 Jan 2013, at 1:55 PM

Re: [hibernate-dev] [Search] Dynamic sharding configuration

[Emmanuel Bernard]

On Tue 2013-09-24 14:30, Sanne Grinovero wrote:
> On 24 September 2013 14:12, Hardy Ferentschik  wrote:
> > 2) remove 'String[] getShardIdentifiers(Class entity, Serializable id, 
> > String idInString)' from ShardIdentifierProvider
> 
> +1 we're automatically assuming a deletion needs to be routed to all
> identifiers.

Bad idea as I explained in my previous email. Plus we could already make
use of that if we reuse Hibernate ORM's tenantid value.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Nice posts on Hibernate Search

[Emmanuel Bernard]

You should blog and tweet them.

On Tue 2013-10-01 11:51, Sanne Grinovero wrote:
> Found this nice blog post:
> 
> http://timontech.net/2013/08/27/adding-the-power-of-search-to-your-hibernate-app-the-easy-way/
> 
> He makes a good point on when it's useful to use.
> 
> there also is a nice follow-up in form of a dzone quickstart:
> https://twitter.com/DZone/status/384374190066765827
> 
> 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] checkNullability when deleting an entity

[Emmanuel Bernard]

On Mon 2013-09-23 17:07, Steve Ebersole wrote:
> Anyone have compelling reasons to continue to call 
> org.hibernate.engine.internal.Nullability#checkNullability when deleting 
> an entity?

An entity being deleted can be validated by Bean Validation. But from
what I understand you would not call checkNullability and thus leave
room for BV to be called. Correct?

> To a lesser degree, how about reasons for calling 
> org.hibernate.engine.internal.ForeignKeys.Nullifier#nullifyTransientReferences
>  
> when deleting?
> ___
> 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] Nice posts on Hibernate Search

[Emmanuel Bernard]

> BTW I just received this email some minutes ago, but it says "sent 22 hours 
> ago"

Pretty good for i18l delivery. Fedex can be faster but not all the time.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Dynamic sharding configuration

[Emmanuel Bernard]

I don't have much stake in the specialized method vs context object
debate as indeed the interface is very specialized and prone to changes.
But as Sanne mentioned, there are memory pressure consequences if this
call is in the hot path.

It is correct that the current use of ForDeletion requires to use a non
remote non async backend at the moment. That's something I discussed
with Sanne back when I implemented it.
It's not hard to imagine how we could transport such information in a
later version but that would require additional contracts.

The use case I designed dynamic sharding for is to:

- create one index per user (think login)
- query only by a specific index
- apply mutation and deletion on a single index
- support 100s users (ie shards) per VM instance

I also had Bloom filters in mind when I designed the original sharding
strategy.

For these scenarios, a smart ForDeletion is necessary as you don't want to
open / query hundreds of indexes unnecessarily.

That Hardy thinks the use case is wrong is beyond me but if that's the
general feeling, that's fine, I'll fork Hibernate Search and make it
useful for me.
For the record, I handed over a working solution 6 months short of 4
days... I am sure it was not perfect, but certainly not 6 months
away from it. I know you guys wanted support to inject a Session to
resolve shards which has put some significant constraints on the life
cycle. But still.

Conclusion

Draw your own, I'm out of it.

Emmanuel

On Mon 2013-10-07 16:03, Sanne Grinovero wrote:
> On 2 October 2013 14:34, Emmanuel Bernard  wrote:
> > On Tue 2013-09-24 14:30, Sanne Grinovero wrote:
> >> On 24 September 2013 14:12, Hardy Ferentschik  wrote:
> >> > 2) remove 'String[] getShardIdentifiers(Class entity, Serializable 
> >> > id, String idInString)' from ShardIdentifierProvider
> >>
> >> +1 we're automatically assuming a deletion needs to be routed to all
> >> identifiers.
> >
> > Bad idea as I explained in my previous email. Plus we could already make
> > use of that if we reuse Hibernate ORM's tenantid value.
> 
> I've tried hard to find an agreement on this, but it seems we're
> wasting time without making progress.
> I'm not happy in ignoring a strong recommendation from any of you,
> very hard choice :-(
> 
> Hardy are you going to reconnect later? Could you reply to this email
> of Emmanuel?
> 
> I'm inclined to add the method back, so that it's the users choice to
> pick his battle. As mentioned below, I don't think we should take
> options away from them.
> Of course our template implementation could provide a sensible default
> method, so all users looking for simplicity don't need to bother too
> much about the extra method.
> 
> @Emmanuel the last conversation we had on the subject is below:
> 
> --Sanne
> 
> [15:05]  hardy: on the dynamic shard id concerns rised
> by emmanuel, I thought you where going to propose a pair of method
> names that would suite you?
> [15:05]  I still think we need to restore the missing method.
> [15:05]  I don't think so
> [15:06]  emmanuel had quite a strong opinion about it,
> don't think it's fair to ignore that.
> [15:06]  I thought more about it and I think the use case is
> not even imlementable
> [15:06]  you have a point there.
> [15:06]  well, I think he is wrong
> [15:06]  take his use case
> [15:06]  he wants to use some sort of customer id or ORM shard 
> identifier
> [15:07]  sounds great, but there is no such context to get it from
> [15:07]  so what can you do in this case?
> [15:07]  a ThreadLocal
> [15:07]  and that's exactly the problem
> [15:07]  if the shards id were determined at the document built
> time (as we want to do it ), it might be possible
> [15:07]  amazing how often "context" is problematic :)
> [15:08]  he he
> [15:08]  no. as far as I understood,he was planning to
> get a reference to the Strategy, and then invoke setters on it to
> "program" the thing.
> [15:08]  but now the shard identifiers are "generated" when the
> changes are getting applied to the index
> [15:09]  that's happening on a different thread
> [15:09]  hardy: we're going in circles with this
> debate on abstract hypothesis. Emmanuel said he has a use case for it,
> and implemented it. that should be good enough for us?
> [15:09]  no
> [15:09]  I honestly would like to see the code first
> [15:09]  :-) let me try a proposal
> [15:10]  and how does it work in a clustered environment
> [15:10]  or JMS
> [15:10]  I seriously doubt we can implement this in a decent way atm
> [15:10]  WDYT of this plan: we re-introduce the
> method, and prov

Re: [hibernate-dev] [OGM] Requiring Java 7?

[Emmanuel Bernard]

No strong opinion.
To me Java 7 is of little value. Java 8 on the other hand...

BTW, will we have trouble with servers that do expect Java 6? I suspect
WF is already on 7 so we don't have that problem on that side.

Emmanuel

On Wed 2013-10-09 13:55, Gunnar Morling wrote:
> Hi,
> 
> In the context of the notorious JavaDoc CSS issue ([OGM-341] - an updated
> stylesheet is required when building our projects with Java 7) Sanne,
> Davide and I were wondering whether we should take the opportunity and
> actually require Java 7 as the minimum version for Hibernate OGM, not only
> at build but also at run time.
> 
> This would give us some interesting opportunities for the implementation,
> language-wise (e.g. diamond operator, multi-catch) as well as library-wise
> (e.g. the fork/join framework). On the downside we might exclude some users
> who are still running on Java 6.
> 
> Given that OGM is a rather new project, I'd assume though that at this
> point most users are in a more experimental stage of using it. I'd thus
> also expect that they use a more current version than 6 which has reached
> the end of its (public) support lifecycle. So this change might not effect
> many in reality.
> 
> Any thoughts?
> 
> --Gunnar
> 
> [OGM-341] https://hibernate.atlassian.net/browse/OGM-341
> ___
> 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] [HV] HV and RESTEasy integration

[Emmanuel Bernard]

I was once again working on the demo showing Bean Validation and its
integration inside Java EE 7.
When you put constraints on the method parameter of a JAX-RS call, you
get a nice rendering of the error on the client side (basically the
HTTP entity returns a JSON representation of the errors).

But if from this method you call JPA or Bean Validation directly and a
ConstraintViolationException is raised, then this exception is processed
as a generic exception crossing RESTEasy.

Would it make sense you think to treat ConstraintViolationException
raised by JAX-RS methods like we would do parameter or return value
exceptions?

The error handling would be the same / unified. I might miss some parts
of the whole picture so this email is really for discussions.

WDYT?

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

[hibernate-dev] [OGM] Neo4J discussions

[Emmanuel Bernard]

Davide and I had an interesting discussion on OxM and Neo4J with
Nicolas. We also brushed on the JCA support and lack of Neo4J interest
in it.

This is a dump of the conversation and a way to continue the
conversation in the open.

## JCA support

Provided outside of Neo4J's team help.
Original author has unplugged from the internet.

## Blueprints

Nicolas, recommended us to look at Blueprints which offers an
abstraction over Neo4J APIs with clearer concepts. Blueprints is
implemented for other Graph databases so we would gain support for them
too for "free".

https://github.com/tinkerpop/blueprints/wiki

Davide looked at it and our use of Neo4J seems simple enough that we
could switch to Blueprints easily.

## Mapping model

We discuss the various mapping modeling strategies to represent an
object graph in a GraphDB.

### Hibernate OGM's approach (aka classic)

An entity is mapped as a node. A property is added to save the name of the
table that maps the entity.
Attributes of the entity are mapped as properties.
A unidirectional association is mapped as a neo4j Relationship where the
starting node is the owner of the relationship. The type of the
relationship is the name of the association.
A bidirectional association is mapped using two relationships, one for each
direction.
A sequence is stored in a node with the value stored in a property, Every
time we need to update the value of the sequence we acquire a lock on the
node.

Node and relationships are stored into two separate lucene indexes and when
I need to retrieve them I use a lucene query.
I've developed the code using Neo4j 1.9.4 (I'm now moving to Neo4j 2)

### Gaedo (aka vertex per property)

Each element (be it a model
entity or one of its property) was mapped directly as a node in graph.
Look here for more infos :

http://riduidel.github.io/gaedo/site/0.4.21/gaedo-blueprints/1_gaedo_graph_storage.html
The main advantage of this approach is that we do not have to browse
(and maintain) an index to find objects for which the property "name"
has the value "foo". instead, we directly locate the vertex holding
that value, then back-navigate the links named "name" to find objects
..; well, I guess you can see the advantage of this approach.

Which takes me back to that divide between properties stored as
properties of vertex, or as distant vertices.
Each approach has its advantage :
 - one vertex per literal ensures easy search through graph navigation
 languages (be them gremlin, cypher, or any other one you find) and
 some nice-to-architect similarity for all vertices (in my case, each
 graph vertex has two properties mimicking the ones found in RDF
 concepts : kind and value). The cost of it being easier lock (it
 indeed seems neo4j requires a lock on each vertex when adding/removing
 an edge connecting them)
 - one property per literal avoids those locking issues, but obviously
 make search really dependant upon indices, and furthermore impossible
 to write using "pure" graph query language,a s queries will sometimes
 rely upon indices navigation, and sometimes upon graph navigation,
 which maybe hard to differentiate - or maybe not.

### Mapping conclusion

After a few back and forth we concluded that the vertex per property
approach does not offer much advantages including in query performances.
Quite the contrary, there are a few advantages to the classic and
natural approach like lower deadlock rate, possibly faster queries etc).
So we will start with this approach in Hibernate OGM and see where it
leads us.

### Data points

Some info on the Neo4J storage
http://digitalstain.blogspot.fr/2011/11/rooting-out-redundancy-new-neo4j.html

## Id generators

I would be nice to implement a generator that uses Neo4J's internal id
property generated for each node. While it is not monotonic, it is a
viable id generator option.

Note that seuqnce mapping still requires to store the sequence seed and
using the Neo4J id property won't be of help here.

That's a condensed version of the discussion. We can continue from there
if needed.

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

[hibernate-dev] [OGM] Option identity

[Emmanuel Bernard]

Gunnar has I had a long discussion and disagreement on the behavior of Option 
in Hibernate OGM that we could not resolve. We would like your feedback.

I did design Option to represent three key concepts:

- an option family - for example named query
- an option per se - for example the combination of the named query family and 
the query name
- an option value - for example the named query value (the HQL)

These notions used to be separated in a previous incarnation but for the sake 
of simplification, we decided to merge option and option value.

So when I designed Option I added the notion of option identifier that combined 
with an option class (the family) would uniquely identify an option. This 
notion is represented by getOptionIdentifier() which is used by equals() and 
hashCode(). The idea is that an Option instance uniquely identifies an option 
and that we could detect when a user tries to define the same option several 
times (with or without different values).

We have two kinds of options:

- generic options like named query that required an additional key to be 
uniquely identified
- unique options like show_sql where the option family and the option are one 
and the same thing

In the unique option case, a UniqueOption subclass force the implementation of 
getOptionIdentifier so that equals / hashCode are true if the same option / 
option family are requested.

A goal of getOptionIdentifier() was to free the Option implementor from 
thinking too much about the equals() / hashCode implementation and just focus 
on the option identity.

Now Gunnar had a concern when he experimented with unique options

class ShowSql extends UniqueOption {
private String value;
public ShowSql(String value) {
this.value = value;
}
public static ShowSql TRUE = new ShowSql("true");
public static ShowSql FALSE = new ShowSql("false");
}

In this situation, ShowSql.equals(ShowSql.FALSE) == true and that bothers him.

So he changed the implementation of Option / UniqueOption to behave like I 
previously explained for generic options but to properly return 
ShowSql.equals(ShowSql.FALSE) == false. To do so, he removed 
getOptionIdentity() and manually ask (Unique)Option implementors to implement 
equals. In his example equals for ShowSql would be based on the value.

So we are at an impasse.

I hate his approach as the equals behavior is inconsistent between generic 
options and unique options. It's very confusing for an Option implementor to 
figure out what equals should do. And ice on the cake, the implementor has to 
implement equals / hashCode instead of delegating that to the superclass: more 
code, more opportunities to screw it up.
To me the fact that ShowSql.equals(ShowSql.FALSE) == true is indeed inelegant 
but AFAIAC is a degenerate case and shifts the identity from Option to Option + 
Option Value which is useless.

Gunnar cannot figure out what I am even saying and to him equals() should 
behave naturally period and the hell with consistency.

I see four ways out:

1. we stay how it is today with the weird equals behavior in case of constants 
and keep the concept that an Option is not identified by its value.
2. we move to Gunnar's position that an Option is uniquely identified by its 
family + value for unique options and keep generic options identity by family + 
key (and not value)
3. we move to Gunnar's position but all the way: an Option is uniquely 
identified by its family + value both for generic and unique options
4. we fall back to differentiate in the type system option family, option key, 
and option value.


So what do you guys all think of this problem?

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

Re: [hibernate-dev] [OGM] Option identity

[Emmanuel Bernard]

On Mon 2013-10-21 17:17, Gunnar Morling wrote:
> 2013/10/21 Emmanuel Bernard 
> So he changed the implementation of Option / UniqueOption to behave like I
> > previously explained for generic options but to properly return
> > ShowSql.equals(ShowSql.FALSE) == false. To do so, he removed
> > getOptionIdentity() and manually ask (Unique)Option implementors to
> > implement equals. In his example equals for ShowSql would be based on the
> > value.
> >
> 
> That's not quite right, maybe this already is the source of our
> disagreement. I only removed the final implementation of
> UniqueOption#getOptionIdentifier() (which was based on the specific
> sub-type of UniqueOption). Option#getOptionIdentifier() is still in place.
> 
> So an option implementor has to implement getOptionIdentifier() in both
> cases, for unique and non-unique options. He doesn't have to implement
> equals() himself (which is implemented in the Option super-class and takes
> into account the specific option type and the result of
> getOptionIdentifier()).
> 
> >
> > So we are at an impasse.
> >
> > I hate his approach as the equals behavior is inconsistent between generic
> > options and unique options. It's very confusing for an Option implementor
> > to figure out what equals should do. And ice on the cake, the implementor
> > has to implement equals / hashCode instead of delegating that to the
> > superclass: more code, more opportunities to screw it up.
> >
> 
> As outlined above an option implementor only needs to provide
> getOptionIdentifier(). The only difference to the situation before is that
> he needs to provide that method for unique option types now, too.
> 
> Does this alleviate your concerns about the proposed change?

This removes the argument against the overhead of rewriting equals.
Strange that I did remember seeing actual equals reimplementations.
Anyways, no that does not solve my fundamental concern that it remains
inconsistent how you implement getOptionIdentifier between unique and
generic options.

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

[hibernate-dev] Thinking about Forge 2 plugins

[Emmanuel Bernard]

We probably should think about what it would mean to help people get
started with our projects using Forge. The Eclipse integration looks
very impressive and very much how I wish I could work to add layers.

I'll add it to the team meeting agenda.

Emmanuel

Date: Mon, 21 Oct 2013 18:27:12 -0400 (EDT)
From: Lincoln Baxter 
To: The Core 
Subject: The Forge 2 philosophy in 4 minutes

Check out the video describing Forge 2 and where we are headed:
   http://www.youtube.com/watch?v=Dpou-FWWatI

Just a quick update on the Forge project. This video will show you what we've 
been working on for the past while: namely a new architecture to allow extreme 
embed-ability, and real code re-use between addons (using our Modular 
container, called Furnace) https://github.com/forge/furnace (based on JBoss 
Modules and Maven). It does not go into great detail into many of these things, 
but is more of a high-level overview of the goals and features.

So what does this mean for your project?

 1) Primarily, this means that you'll be able to work with us to create tools 
for your project that run in all of our supported environments and IDEs. 
Ideally this tooling should be focused on getting users started with your 
projects quickly, so if you're interested in having a Forge plugin for your 
project, please send me an email off list, and we will get the process started. 
We are currently preparing for the launch of our new website, so it will 
probably still be a few months before we can do any intensive project addon 
development with teams.

 2) What this means in reality is that you can deliver tools that will run in 
JBDS and the command-line (and eventually IntelliJ, and NetBeans, and Web IDE), 
without worrying about coordination with an actual product release. Your 
release cycle is completely independent of ours. (Unless you are waiting for a 
new feature that is not yet released.)

To learn more about Forge 2, please visit our github repository: 
https://github.com/forge/core#jboss-forge-20

Expect to hear more from us soon :) We want *YOU*... and your projects of 
course :)

--
Lincoln Baxter, III
JBoss, by Red Hat
lbax...@redhat.com

"If you want something, you'll find a way; if you don't, you'll find an excuse."
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Supporting Cassandra

[Emmanuel Bernard]

Khan did the initial work but Cassandra client APIs were in a big flux
when he worked on it. That may have stabilized over the latest CQL.
I am CCing Khan. I think he is still on Earth somewhere.

Emmanuel

On Mon 2013-11-04 16:17, Gunnar Morling wrote:
> Hi,
> 
> There is a pull request for adding support for Cassandra to OGM [1] which
> has been created quite a long time ago.
> 
> Does anyone have details about it, e.g. what would need to be done in order
> to integrate it? I guess it will need some work due to recent changes in
> OGM and we might also benefit from younger additions to Cassandra itself.
> Also query support should be doable now.
> 
> I'd be interested in taking this over but first would like to make sure I
> better understand what's the current status of this dialect.
> 
> Thanks,
> 
> --Gunnar
> 
> [1] https://github.com/hibernate/hibernate-ogm/pull/164
> ___
> 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] rsync error for ORM 4.2's docs?

[Emmanuel Bernard]

http://docs.jboss.org/hibernate/orm/4.2/

contains the docs, the API but also the whole project structure like
buildSrc, gradle directory etc.
Is that an rsync glitch or something intentional?

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

Re: [hibernate-dev] [OGM] RowKey vs. EntityKey

[Emmanuel Bernard]

As we discussed on Irc but for posterity.

EntityKey represents what you need to reach an entity. It contains both the 
actual id information and the metadata necessary to do the query.
Likewise, we have AssociationKey that does represent an association navigation.
RowKey is used to represent two things:
- each entry key  in an association navigation (which is conceptually a map)
- the unique identifier to reach a sequence or a table generator entry

I tend to like the fact that these are typed differently so in a way I'd split 
the RowKey in two more than merge everything together. If anything it makes is 
easier for a GridDialect writer to understand what's going on. Davide pointed 
out that a common super interface might be useful in a couple of places.

Emmanuel

On 8 nov. 2013, at 13:20, Gunnar Morling wrote:

> Hi,
> 
> This may be a noob question, but what is the difference between RowKey and
> EntityKey in OGM?
> 
> Both seem to represent one row (by means of table name + key column names +
> column values), albeit being implemented a bit differently. Could they be
> merged into one class?
> 
> 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] [Search] Facet counts

[Emmanuel Bernard]

We had the debate in the past but I do agree with the second point of
this user
http://outbottle.com/hibernate-search-multivalue-facet-counts/

Very confusing when I am in this situation.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [OGM] Build time

[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.
b. Provide a -Dcomplete flag to run in case 3.
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.

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.

Thoughts?

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

Re: [hibernate-dev] [OGM] Build time

[Emmanuel Bernard]

On Thu 2013-11-28 10:45, Gunnar Morling wrote:
> 2013/11/28 Emmanuel Bernard 
> > 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?

Not that would be to build all backends. That's use case #2.

> 
> 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?

This does cover case #1.
My personal problem is 1. I can't remember that it's pl / am. And when I
do, I can't remember what pl does vs am.
I guess if maven had some autocompletion logic I might be less
concerned.

> 
> 
> 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.

Ah, yes that sucks.

> 
> 
> > 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.
> 

That's ok for case #2. But not #1.

> 
> > 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.
> 

The concern I have is someone cloning OGM and getting a BUILD FAILED in
his face. That's not even mentioning the 2.3km of logs to dig into to
figure out why.

I guess I'll have to go for a custom script...
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Build time

[Emmanuel Bernard]

On Thu 2013-11-28 12:55, Gunnar Morling wrote:
> 2013/11/28 Gunnar Morling 
> 
> >
> >
> >
> > 2013/11/28 Hardy Ferentschik 
> >
> >>
> >> > How about
> >> >
> >> > d. Use an alias for all skip options:
> >> >
> >> > export mvnFast = "mvn -DskipITs -DskipDocs -DskipDistro”
> >>
> >> instead of using a variable, just use an alias. I have several aliases
> >> defined in my ~/.alias file which I source from .bashrc.
> >>
> >
> > Yes, that's what I've actually meant to say. Still too early in the
> > morning ;-)
> >
> 
> We could actually commit a build.sh script which accepts a "skipAll"
> parameter and forwards this to mvn by splitting it up into the single skip
> options. All other options would be passed along as is. This would give us
> a concise skip all command, while maintaining control in case its needed.
> This script could also increase the perm gen space.
> 
> Would that help your case, Emmanuel?

Let me play with aliases and if needed a build.sh. It's just that I keep
spending time improving tools to work more efficiently but at the end of
the day, I'm questioning my ROI ;)
___
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

[Emmanuel Bernard]

I am quite uncomfortable with that approach.

Here is what I propose instead (we did discuss that in the past a bit).

Rules by decreasing precedence:

property | association > class > super class > global 
(*) question: what about overridden properties

For a given level mentioned above,
API > annotation > file/property based configuration

This is how JPA does it (API overrides annotations per level), same for
Hibernate Search and I suspect Hibernate Validator. I never had anything
bad to say about this approach in my past experience.

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
> 
> 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] Precedence of options specified on different levels

[Emmanuel Bernard]

On Tue 2013-12-03 17:48, 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.

Realize guys that we have a sparse matrix model. Not all settings will
be applicable globally AND per entity AND per property.
host for example, probably should not have a entity/property level. We
might want to allow for it to be set programmatically globally but in
that case, I'd argue that the program should have priority over the XML.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Distinguishing embedded collections and associations in document stores

[Emmanuel Bernard]

We probably need to revisit what we really want to test and adjust the
test accordingly. AFAIR, these tests felt weak anyways.

On Fri 2013-11-29 11:49, Gunnar Morling wrote:
> Hi,
> 
> I'm working on support for embedded associations in CouchDB [1]. Checking
> how this is mapped by the MongoDB dialect I saw its done like this (here
> with an order column):
> 
> {
> "_id": "123",
> "orderedChildren": [
> {
> "birthorder": 0,
> "orderedChildren_id": "456"
> },
> {
> "birthorder": 1,
> "orderedChildren_id": "789"
> }
> ]
> }
> 
> Just looking at this document one can't tell whether "orderedChildren"
> actually represents an association or an embedded collection. For our
> engine that's no problem as it knows the kind of the element from its
> meta-model.
> 
> We have a testing approach though which makes assertions on the number of
> associations stored in the database. With the representation described
> above the number of embedded associations can't be determined on the
> server-side alone (using a "view" in CouchDB terms).
> 
> Besides from adding an attribute which describes the kind of a collection
> (which wouldn't be so nice as it was just for testing purposes), I don't
> see any other way than obtaining all the candidates and single out actual
> associations on the client based on the meta-model.
> 
> Maybe anyone has a better idea?
> 
> Btw. for MongoDB the problem is ignored by having the assertion method
> always return true in this case.
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/OGM-389
> ___
> 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

[Emmanuel Bernard]

On Wed 2013-12-04 10:33, Gunnar Morling wrote:
> 2013/12/3 Emmanuel Bernard 
> 
> > On Tue 2013-12-03 17:48, 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.
> >
> > Realize guys that we have a sparse matrix model. Not all settings will
> > be applicable globally AND per entity AND per property.
> > host for example, probably should not have a entity/property level.
> 
> 
> Yes, sure.
> 
> 
> > We
> > might want to allow for it to be set programmatically globally but in
> > that case, I'd argue that the program should have priority over the XML.
> >
> 
> Why would you argue that way?
> 
> IMO one needs to distinguish two different categories of properties here.
> API > XML makes sense for properties where the XML property defines a
> default in case no value is given via other means; hence the suggested
> "default..." prefix. Association storage is an example; there are no
> associations to be stored on the global level per-se, instead giving the
> value via XML or globally acts as fallback in case no value is specified
> for a given association.
> 
> But there is another category of properties where the value from XML,
> hibernate.properties etc. ultimately should be applied. The host falls into
> this category. Often such setting is configured by someone executing
> deployments, e.g. by providing a properties file within the environment,
> rather than by a developer. So one can take one and the same artifact,
> deploy it in different environments and have it work with different
> database hosts.
> 
> I'd even argue that setting the host via the API is not really useful for
> that reason. But if it is possible to set this value via the API, the
> XML/properties value should take precedence IMO.

I do disagree.
First off, I am not certain host should be an option. It could just
remain a property.
But assuming we want an API way to define host, I think it should have
priority over properties. That way, I can write a piece of code that
takes the host value from somewhere and apply it. This piece of code can
even read that value from persistence.xml if it wants to.
Why would you have a programmatically defined host just to have it be
erased by the static xml/properties file?

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

[hibernate-dev] Hibernate has a new website

[Emmanuel Bernard]

http://hibernate.org has been completely revamped.

The entire team has been working on it for a long time. I am personally
very happy to see this puppy out.

Our goals were:

* to help newcomers understand what each Hibernate project is about and why it 
matters
* to help regular / advanced users to find what they are looking for quickly
* to give higher visibility to what mattered most
* to clarify the fact that Hibernate is an umbrella of (awesome) projects

The infrastructure is also much easier and flexible (you can even contribute
pull-requests to fix typos or improve the site). You will see additional
improvements over the coming months. Especially around better integrated
documentation.

Let us know what you think and of any glitch you might see.

http://hibernate.org

Emmanuel

PS: the DNS propagation might take a little while
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ArrayIndexOutOfBoundsException in ReflectionHelper.parametersResolveToSameTypes

[Emmanuel Bernard]

https://hibernate.atlassian.net/browse/HV-818

I am a bit uncertain of the case and frequency when that happens. If
WildFly does plan to stay on the 5.0.x series, we probably want to fix
it in a 5.0.2. Same for the classloader leak I imagine.

Emmanuel

On Wed 2013-12-11 11:23, Ales Justin wrote:
> @Hardy, Emmanuel: https://gist.github.com/alesj/7908062
> 
> Imo, any AIOOBE is a bug.
> 
> -Ales
> 
> ___
> 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] Create OSGi integration test project for all of Hibernate?

[Emmanuel Bernard]

This sounds like a good idea. You will hit the more general problem of the 
compatibility matrix and snapshot against snapshot issue we need to address to 
avoid the micro version incompatibilities that have hit Search and ORM 
recently. 

> On 12 déc. 2013, at 19:29, Brett Meyer  wrote:
> 
> ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator 
> does the same).  Since at least ORM, Validator, and Search have moved or are 
> moving towards supporting OSGi environments, would it make more sense to 
> create hibernate/hibernate-osgi-integration-tests and wire it to a new CI 
> job?  Arguably, they shouldn't be considered a "unit test" to begin with, but 
> that's up for debate.  Thoughts?
> 
> Brett Meyer
> Red Hat, Hibernate ORM
> 
> ___
> 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

[Emmanuel Bernard]

I did not see that thread when I opened the constant naming unification. 

I am a bit skeptical that option should be used for global settings like host 
and co but let's try and see where that leads us. 

On 11 déc. 2013, at 18:36, "Davide D'Alto"  wrote:

>> 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

___
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

[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).

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?

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
> 
> 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] [Search] Spatial still experimental

[Emmanuel Bernard]

When I used it, I was mostly fine with it. I had only a few remarks:

- we should add the support for miles. Only having kilometers was in
  retrospect wrong.
- spatial as a name is a bit fuzzy, should we change it? I tend to use
  geolocation maybe geoquery when I try to explain the notion.
- in the DSL should we rename onCoordinates with onCoordinatesField or
  even onSpatialField?
  The intend would be a bit clearer.
- I frequently makes the mistake of writing my spatial query without
  setting up the index. We might want to try and make that error message
  as descriptove as possible.
- Lucene 4 comes with the notion of spatial queries supporting shapes.
  We should experiment with the DSL to see if that notion can be safely
  added. (I think it does at least on the DSL side).

Emmanuel

On Fri 2013-12-13 17:15, Hardy Ferentschik wrote:
> Hi,
> 
> Given that we are moving to Search 5 and we made some recent adjustments, I 
> am wondering whether it would 
> not be time to remove the experimental status of the spatial Api now? 
> Thoughts?
> 
> —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] JdbcSession -> DataStoreSession

[Emmanuel Bernard]

When I reviewed your work earlier last week, I had the feeling that we
would need to replace JdbcSession with something totally different. OGM
Loader / Persisters would then use that different contract.

The idea of a generic DataStoreSession is attractive.

But something I am not clear on is how the generic parameter of
Operation will be used. How can a Loader or Persister invoking
DataStoreSession.accept() retrieves the results? Will it be ResultSet or
some agnostic container too?

Emmanuel

On Sat 2013-12-14 11:53, Steve Ebersole wrote:
> As Gail and I discussed the actual API to use in this JdbcSession 
> redesign we both liked the idea of sending Operations in to the 
> JdbcSession rather than JdbcSession exposing a very granular, JDBC-like 
> API.  This got me to thinking that JdbcSession really could be a generic 
> representation of a connection+transaction context for *any* back end, 
> whether that back-end was JDBC or not.
> 
> I discussed this idea a bit with Sanne on IRC.  He was on board in the 
> general sense.
> 
> So this morning I spent some time re-working the code to express this 
> concept.  I just pushed this out to my repo.  The main contract now is 
> org.hibernate.resource.store.DataStoreSession.  The JDBC realization of 
> this contract is defined by 
> org.hibernate.resource.store.jdbc.JdbcSession (which extends the 
> DataStoreSession).
> 
> The nice thing is that this all ties in seamlessly with the 
> TransactionCoordinator.  There is a notion of "resource local 
> transactions" and "jta transactions".  "resource local transactions" 
> ultimately come from the DataStoreSession which allows integrating 
> back-end specific notions of transactions by implementing a 
> org.hibernate.resource.transaction.ResourceLocalTransaction for that 
> back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction 
> for example for JDBC).
> 
> Anyway, it was a nice exercise even if y'all decide to not use this in 
> OGM.  It forced me to think about the separation between the 2 main 
> packages (org.hibernate.resource.transaction versus 
> org.hibernate.resource.store) and to remove the cyclic deps.
> ___
> 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

[Emmanuel Bernard]

Only the CouchDB provider in the PR so far. But the idea is to move all
to that model.

On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> Hi guys,
> 
> That sounds nice. Are association storage strategies already using this new
> feature ?
> 
> 
> Guillaume
> 
> 
> 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).
> >
> > 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?
> >
> > 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
> > >
> > > Note that any setting given v

Re: [hibernate-dev] [OGM] Precedence of options specified on different levels

[Emmanuel Bernard]

On Mon 2013-12-16 11:06, 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?

Someone has clearly decided that A.getMe should behave in a specific way
and differently than A.getOtherMe. Overriding that via B for all of A's
properties is wrong IMO. Besides, why doesn't it override the settings
for properties that are not overridden?

> 
> 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.
> 

If you consider that the truth should be in the most specific entity, I think
you should also consider that inheriting the settings from the
superclass is against that principle and that inheritance should not be
involved.

Emmanuel
___
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

[Emmanuel Bernard]

I think in this specific case it does make sense to have a global
setting and a specific one for the additional mongodb if we rephrase
then like think

@StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be AS_SEPARATE_DOCUMENT 
or AS_SEPARATE_ENTRY)
@StoreAssociationsInSeparateCollection //mongo specific

BTW is that a generic setting or something dedicated to document
datastore.
Does it work for k/v? I think it does.
Does it work for GraphDBs?

On Mon 2013-12-16 10:46, Gunnar Morling wrote:
> On a related note, Emmanuel raised the question whether to use the same
> option types for different data stores or not, i.e. should we use the same
> @AssociationStorage annotation and enum for MongoDB and CouchDB?
> 
> Currently there are the following strategies:
> 
> * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
> * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
> 
> So we have IN_ENTITY in both, but the other strategies don't directly map
> to each other. CouchDB doesn't have a notion of "collections", so
> ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
> (considering the one and only document heap as the "global collection",
> whereas that maps to a specific "associations" collection for the MongoDB
> backend).
> 
> So in a shared enum we might have values like these: IN_ENTITY,
> ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
> 
> The latter would only be supported on MongoDB and raise an exception when
> used with CouchDB. To make the options usable for other document stores as
> well, I think we should avoid datastore specific terms such as "collection"
> in the enum values.
> 
> As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT on
> the shared enum (It seems quite save to assume that this makes sense in
> every document store). The MongoDB dialect could then provide an additional
> option which allows to specify the store-specific collection vs. global
> collection aspect:
> 
> @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
> @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
> annotation/enum
> 
> I slightly prefer that last approach because it doesn't expose any specific
> things on the shared contracts, although increasing the complexity a bit by
> having two options for MongoDB.
> 
> --Gunnar
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 2013/12/16 Emmanuel Bernard 
> 
> > Only the CouchDB provider in the PR so far. But the idea is to move all
> > to that model.
> >
> > On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> > > Hi guys,
> > >
> > > That sounds nice. Are association storage strategies already using this
> > new
> > > feature ?
> > >
> > >
> > > Guillaume
> > >
> > >
> > > 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;}
> > > >

Re: [hibernate-dev] Released Hibernate Search 4.4.2.Final and 4.5.0.Alpha2

[Emmanuel Bernard]

Hum, what drove this?
Last time I chatted with Jason, the idea was to not have WF integrate
Hibernate Search in the base distro.
What is the consumer of the base technology? Infinispan in WF does not
require HSearch for the base clustering features right?

Emmanuel

On Mon 2013-12-16 11:19, Ales Justin wrote:
> Did you create a PR in WildFly, with the upgrade.
> As HS is now part of upstream master. ;-)
> 
> On 16 Dec 2013, at 00:14, Sanne Grinovero  wrote:
> 
> > Hello all,
> > both releases where done specifically to address one bug, as explained
> > on the traditional release blog post:
> >  
> > http://in.relation.to/Bloggers/HibernateSearchWeekendReleasesFromBothMaintenanceBranches
> > 
> > Best,
> > 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] JdbcSession -> DataStoreSession

[Emmanuel Bernard]

In the old (4.2) Persisters / Loaders, the ResultSet API was pretty pervasive
and passed form methods to methods.
With the Operation approach, that cannot be the case anymore. But if
that can be done, that's better for OGM.

Also, that's a bit out of my league, but I wonder if that operation
design can lead to too much memory pressure due to more objects being
created. Maybe that's just premature optimization at this stage.

Emmanuel

On Mon 2013-12-16  7:24, Steve Ebersole wrote:
> The Operations are store specific.  So there would be a specific Operation
> for performing a JDBC query and either extracting the results (normal use)
> or accessing the ResultSet (ScrollableResults use).   There would be some
> other Operation impl(s) for doing the same against no-sql stores.  Operation
> is really meant to be model an end-to-end interaction with the backing
> store.
> 
> The thing that "clicked" for me was realizing that even though each back-end
> would need varying Operation impls almost all of these usages come from
> persisters and loaders which OGM already provides alternatives for.  We'd
> just replace them (persisters/loaders and DataStoreSession types) in tandem.
> 
> Keep in mind that the idea here is simply to centralize the binding of
> connection+transaction in various transaction scenarios and encapsulate
> handling of "flow" between them.
> 
> 
> 
> On Mon 16 Dec 2013 01:38:22 AM CST, Emmanuel Bernard wrote:
> >When I reviewed your work earlier last week, I had the feeling that we
> >would need to replace JdbcSession with something totally different. OGM
> >Loader / Persisters would then use that different contract.
> >
> >The idea of a generic DataStoreSession is attractive.
> >
> >But something I am not clear on is how the generic parameter of
> >Operation will be used. How can a Loader or Persister invoking
> >DataStoreSession.accept() retrieves the results? Will it be ResultSet or
> >some agnostic container too?
> >
> >Emmanuel
> >
> >On Sat 2013-12-14 11:53, Steve Ebersole wrote:
> >>As Gail and I discussed the actual API to use in this JdbcSession
> >>redesign we both liked the idea of sending Operations in to the
> >>JdbcSession rather than JdbcSession exposing a very granular, JDBC-like
> >>API.  This got me to thinking that JdbcSession really could be a generic
> >>representation of a connection+transaction context for *any* back end,
> >>whether that back-end was JDBC or not.
> >>
> >>I discussed this idea a bit with Sanne on IRC.  He was on board in the
> >>general sense.
> >>
> >>So this morning I spent some time re-working the code to express this
> >>concept.  I just pushed this out to my repo.  The main contract now is
> >>org.hibernate.resource.store.DataStoreSession.  The JDBC realization of
> >>this contract is defined by
> >>org.hibernate.resource.store.jdbc.JdbcSession (which extends the
> >>DataStoreSession).
> >>
> >>The nice thing is that this all ties in seamlessly with the
> >>TransactionCoordinator.  There is a notion of "resource local
> >>transactions" and "jta transactions".  "resource local transactions"
> >>ultimately come from the DataStoreSession which allows integrating
> >>back-end specific notions of transactions by implementing a
> >>org.hibernate.resource.transaction.ResourceLocalTransaction for that
> >>back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction
> >>for example for JDBC).
> >>
> >>Anyway, it was a nice exercise even if y'all decide to not use this in
> >>OGM.  It forced me to think about the separation between the 2 main
> >>packages (org.hibernate.resource.transaction versus
> >>org.hibernate.resource.store) and to remove the cyclic deps.
> >>___
> >>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: Re: [OGM] Precedence of options specified on different levels

[Emmanuel Bernard]

___
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

[Emmanuel Bernard]

Yes, verbs might not work well esp since JPA does not use that style.
I kinda liked the vibe :)

On Mon 2013-12-16 17:24, Gunnar Morling wrote:
> 2013/12/16 Emmanuel Bernard 
> 
> > I think in this specific case it does make sense to have a global
> > setting and a specific one for the additional mongodb if we rephrase
> > then like think
> >
> > @StoreAssociations(IN_ENTITY, AS_DOCUMENT) (should it be
> > AS_SEPARATE_DOCUMENT or AS_SEPARATE_ENTRY)
> > @StoreAssociationsInSeparateCollection //mongo specific
> >
> 
> I'm a bit concerned about this naming approach using verbs. It reads nicely
> here, but does it work as well for other cases? E.g. take the write concern
> option, @WriteConcern(ACKNOWLEDGED) seems very natural, how would that look
> with the verb- based style? I feel with a declarative style using nouns
> such as @AssociationStorage we may be on the safer side.
> 
> BTW is that a generic setting or something dedicated to document
> > datastore.
> > Does it work for k/v? I think it does.
> > Does it work for GraphDBs?
> >
> 
> I was wondering the same. Not sure about graph DBs, I guess not?
> 
> 
> > On Mon 2013-12-16 10:46, Gunnar Morling wrote:
> > > On a related note, Emmanuel raised the question whether to use the same
> > > option types for different data stores or not, i.e. should we use the
> > same
> > > @AssociationStorage annotation and enum for MongoDB and CouchDB?
> > >
> > > Currently there are the following strategies:
> > >
> > > * MongoDB: GLOBAL_COLLECTION, COLLECTION, IN_ENTITY
> > > * CouchDB: ASSOCIATION_DOCUMENT, IN_ENTITY
> > >
> > > So we have IN_ENTITY in both, but the other strategies don't directly map
> > > to each other. CouchDB doesn't have a notion of "collections", so
> > > ASSOCIATION_DOCUMENT is most similar to GLOBAL_COLLECTION from MongoDB
> > > (considering the one and only document heap as the "global collection",
> > > whereas that maps to a specific "associations" collection for the MongoDB
> > > backend).
> > >
> > > So in a shared enum we might have values like these: IN_ENTITY,
> > > ASSOCIATION_DOCUMENT, ASSOCIATION_DOCUMENT_ORGANIZED_BY_ASSOCIATION.
> > >
> > > The latter would only be supported on MongoDB and raise an exception when
> > > used with CouchDB. To make the options usable for other document stores
> > as
> > > well, I think we should avoid datastore specific terms such as
> > "collection"
> > > in the enum values.
> > >
> > > As an alternative we could have only IN_ENTITY and ASSOCIATION_DOCUMENT
> > on
> > > the shared enum (It seems quite save to assume that this makes sense in
> > > every document store). The MongoDB dialect could then provide an
> > additional
> > > option which allows to specify the store-specific collection vs. global
> > > collection aspect:
> > >
> > > @AssociationStorage(ASSOCIATION_DOCUMENT) //shared annotation/enum
> > > @AssociationDocumentStorage(GLOBAL_COLLECTION) //mongo-specific
> > > annotation/enum
> > >
> > > I slightly prefer that last approach because it doesn't expose any
> > specific
> > > things on the shared contracts, although increasing the complexity a bit
> > by
> > > having two options for MongoDB.
> > >
> > > --Gunnar
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2013/12/16 Emmanuel Bernard 
> > >
> > > > Only the CouchDB provider in the PR so far. But the idea is to move all
> > > > to that model.
> > > >
> > > > On Fri 2013-12-13 16:35, Guillaume SCHEIBEL wrote:
> > > > > Hi guys,
> > > > >
> > > > > That sounds nice. Are association storage strategies already using
> > this
> > > > new
> > > > > feature ?
> > > > >
> > > > >
> > > > > Guillaume
> > > > >
> > > > >
> > > > > 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
> > > > > >
> >

Re: [hibernate-dev] [Search] Spatial still experimental

[Emmanuel Bernard]

https://hibernate.atlassian.net/browse/HSEARCH-1469
https://hibernate.atlassian.net/browse/HSEARCH-1470


On Thu 2013-12-19 12:36, Hardy Ferentschik wrote:
> 
> On 16 Jan 2013, at 08:32, Emmanuel Bernard  wrote:
> 
> > - spatial as a name is a bit fuzzy, should we change it? I tend to use
> >  geolocation maybe geoquery when I try to explain the notion.
> 
> not sure. IMO spatial is the right term. I find relocation less appealing, 
> but better than geoquery which
> gets a -1 
> 
> > - in the DSL should we rename onCoordinates with onCoordinatesField or
> >  even onSpatialField?
> 
> +1 for on spatialField
> 
> > - I frequently makes the mistake of writing my spatial query without
> >  setting up the index. We might want to try and make that error message
> >  as descriptove as possible.
> 
> +1
> 
> > - Lucene 4 comes with the notion of spatial queries supporting shapes.
> >  We should experiment with the DSL to see if that notion can be safely
> >  added. (I think it does at least on the DSL side).
> 
> +1
> 
> —hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SessionEventsListener feature (HHH-8654)

[Emmanuel Bernard]

Sanne, I wonder if that could be used as a way to get rid of the weak
identity hash map we have in Hibernate Search. (I think we got rid of
all ThreadLocal already).

Steve, do you think I could (ab)use these as Session level cache? I
think OGM could benefit from such feature in a couple of situations.
That would require that from an eventsource, I could reach the list of
listeners to access the state I suppose.

Emmanuel

On Wed 2013-11-13 15:16, Steve Ebersole wrote:
> I wanted to highlight a new feature in 4.3 as it came about from 
> performance testing efforts.  Its a way to hopefully help track down 
> potential performance problems in applications that use Hibernate. In 
> this way it is similar to statistics, but it operates per-Session 
> (though certainly custom impls could role the metrics up to a SF level).
> 
> It revolves around the SessionEventsListener[1] interface which 
> essentially defines a number of start/end pairs for the interesting 
> events (for example starting to prepare a JDBC statement and ending that 
> preparation).
> 
> Multiple SessionEventsListener instances can be associated with the 
> Session simultaneously.  You can add them programatically to a Session 
> using Session#addEventsListeners(SessionEventsListener...) method.  They 
> can also be added to the Session up-front via the 
> SessionFactory#withOptions API for building Sessions.
> 
> Additionally there are 2 settings that allow SessionEventsListener impls 
> to be applied to all Sessions created:
> 
> * 'hibernate.session.events.auto' allows you to name any arbitrary 
> SessionEventsListener class to apply to all Sessions.
> * 'hibernate.session.events.log' refers to a particular built-in 
> implementation of SessionEventsListener that applies some timings across 
> the start/end pairs 
> (org.hibernate.engine.internal.LoggingSessionEventsListener).  In fact 
> this listener is added by default if (a) stats are enabled and (b) the 
> log level (currently INFO) of LoggingSessionEventsListener is enabled.  
> Below[2] is some sample output of LoggingSessionEventsListener.
> 
> There is also a org.hibernate.EmptySessionEventsListener (no-op) class 
> to help develop custom ones.
> 
> Anyway, as much as anything I wanted to point it out so people can try 
> it out and to get feedback.  I think the API covers most of the 
> interesting events.  If you feel there are any missing, lets discuss 
> here or on a Jira issue.
> 
> 
> [1] https://gist.github.com/sebersole/7438250
> 
> [2]
> 14:40:20,017  INFO LoggingSessionEventsListener:275 - Session Metrics {
>  9762 nanoseconds spent acquiring 1 JDBC connections;
>  0 nanoseconds spent releasing 0 JDBC connections;
>  1020726 nanoseconds spent preparing 4 JDBC statements;
>  1442351 nanoseconds spent executing 4 JDBC statements;
>  0 nanoseconds spent executing 0 JDBC batches;
>  0 nanoseconds spent executing 0 L2C puts;
>  0 nanoseconds spent executing 0 L2C hits;
>  0 nanoseconds spent executing 0 L2C misses;
>  2766689 nanoseconds spent executing 1 flushes (flushing a total of 
> 3 entities and 1 collections);
>  1096552384585007 nanoseconds spent executing 2 partial-flushes 
> (flushing a total of 3 entities and 3 collections)
> }
> ___
> 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] Hibernate Search: Transactions timeout on MassIndexer

[Emmanuel Bernard]

Sorry late here.
OptionallyWrapInJTATransaction is not about timeout. It's about
explicitly starting a JTA transaction like a CMT entity bean would to so
that Hibernate ORM does not complain.

On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
> Hi Emmanuel,
> in case you get very bored at Devoxx :)
> 
> I remember you implementing a quite complex fix for my initial
> MassIndexer which involved avoiding the transactions we use from
> timing out.
> This is probably more than a year old, but there is a user on the
> forums now using 4.4.0.Final and having a suspiciously similar
> problem:
> 
> https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
> 
> 
> I've looked into our code, but I'm not understanding how the class
> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
> is supposed to prevent the transaction from timing out?
> 
> Do you have any idea on the problem?
> I recently had to apply some refactoring so I might have introduced a
> regression but I need another pair of eyes.
> 
> Tia,
> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SessionEventsListener feature (HHH-8654)

[Emmanuel Bernard]

On Mon 2013-12-23 11:37, Gunnar Morling wrote:
> Am 23.12.2013 10:55 schrieb "Emmanuel Bernard" :
> >
> > Sanne, I wonder if that could be used as a way to get rid of the weak
> > identity hash map we have in Hibernate Search. (I think we got rid of
> > all ThreadLocal already).
> >
> > Steve, do you think I could (ab)use these as Session level cache? I
> > think OGM could benefit from such feature in a couple of situations.
> > That would require that from an eventsource, I could reach the list of
> > listeners to access the state I suppose.
> 
> In the OGM case, could such caching facility not be implemented within
> OgmSession? This seems a bit less abusive.

Unfortunately no. There is no link from Hibernate ORM's engine back to
the wrapper.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Search: Transactions timeout on MassIndexer

[Emmanuel Bernard]

I guess you could do it mostly transparently for the user. 
Set a reasonably high timeout like say 2 mins, then every n operation look how 
much
you've consumed. If you are close to the limit, you commit and restart a
transaction.
So your option would be semi public.
hibernate.search.massindexer.transaction_timeout auto|time in (m)s

If a user is in trouble with the auto system, we give him the option.

Emmanuel

On Mon 2013-12-23 14:54, Sanne Grinovero wrote:
> Thanks that explains why I was missing the correlation.
> To avoid the transaction manager to kill our indexing process, I guess
> our only answer today is to reconfigure the transactions manager to
> use larger timeouts?
> 
> That's quite limiting, especially as it requires to change it
> globally; ideally I'd want to ping the TM regularly to let it know
> we're still busy (and doing fine) ?
> 
> I couldn't find a method to do that by looking at the standard
> javax.transaction API, so I'm wondering if we should take advantage of
> some proprietary extensions.
> Other than that, on the standard API I see we could set the TX timeout
> for this specific transaction; we should probably add a new option to
> the MassIndexer API to have the user suggest a
> very-high-but-reasonable timeout?
> 
> Sanne
> 
> On 23 December 2013 10:09, Emmanuel Bernard  wrote:
> > Sorry late here.
> > OptionallyWrapInJTATransaction is not about timeout. It's about
> > explicitly starting a JTA transaction like a CMT entity bean would to so
> > that Hibernate ORM does not complain.
> >
> > On Mon 2013-11-11 17:29, Sanne Grinovero wrote:
> >> Hi Emmanuel,
> >> in case you get very bored at Devoxx :)
> >>
> >> I remember you implementing a quite complex fix for my initial
> >> MassIndexer which involved avoiding the transactions we use from
> >> timing out.
> >> This is probably more than a year old, but there is a user on the
> >> forums now using 4.4.0.Final and having a suspiciously similar
> >> problem:
> >>
> >> https://forum.hibernate.org/viewtopic.php?f=9&t=1029562
> >>
> >>
> >> I've looked into our code, but I'm not understanding how the class
> >> org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction
> >> is supposed to prevent the transaction from timing out?
> >>
> >> Do you have any idea on the problem?
> >> I recently had to apply some refactoring so I might have introduced a
> >> regression but I need another pair of eyes.
> >>
> >> Tia,
> >> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Behavior of GenerationType.IDENTITY with OGM

[Emmanuel Bernard]

The problem is that in JPA, IDENTITY returns a long, not a UUID.

On Mon 2014-01-20 12:23, Gunnar Morling wrote:
> Hi,
> 
> While reviewing the PR for batch operations in OGM [1], I took some time to
> better understand OGM's approaches for id generation.
> 
> Now I'm wondering about how GenerationType.IDENTITY is implemented. The
> corresponding generator (OgmIdentityGenerator) just delegates to a
> table-based strategy, so an id is always pre-allocated and then passed into
> the dialect when creating a tuple.
> 
> I think it would be nice to have proper support for server-generated ids,
> in particular since some stores return the inserted id directly from the
> insert operation, i.e. without requiring another read.
> 
> For the time being, as the current implementation doesn't really adhere to
> the semantics of GenerationType.IDENTITY, should we raise an error when
> using it instead of silently using another strategy?
> 
> Thoughts?
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/OGM-175
> ___
> 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] merge on new entities

[Emmanuel Bernard]

We might, but to add to the complexity, Hibernate ORM uses "merge" plans
to optimize the number of selects for a given object graph merged.
A non associated object being merged might be more common though, not
sure.

On Mon 2014-01-27  9:14, Sanne Grinovero wrote:
> Thanks!
> yes we got to that conclusion. The question came from Radim in
> Infinispan team attempting to figure out how to squeeze some more
> performance from the JPACacheStore from Infinispan.
> 
> It's tricky that in Infinipan we don't know if something is a new
> entry or an update; I had a highly customized MySQL CacheStore which
> used the "INSERT OR UPDATE" statement, a non-standard feature from
> that DB which is very useful for this case.
> 
> Could be interesting for Hibernate ORM to think of a JPA merge
> implementation which could take advantage of such custom extensions?
> Requires quite a different Dialect API.
> 
> Sanne
> 
> On 27 January 2014 09:07, Emmanuel Bernard  wrote:
> > If the id is assigned, we do a select first. Not super efficient but
> > that's about the only thing you can do.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 4.5.0.CR1 on staging and not in prod

[Emmanuel Bernard]

On the website, Staging has a commit related to HSearch's release. That
commit is not on production. Is that expected?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] OGM depending on ORM 4.3

[Emmanuel Bernard]

To follow up on the PR migrating OGM to ORM 4.3. I think it is the right
thing to do but I wonder whether we should do a tag / release of
Hibernate OGM before that. So that people still using the JPA 2.0 series
have a final version and a point for fork.

What has happened between the latest OGM version and now - aside from a
long time that is :)

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

Re: [hibernate-dev] [OGM] When is AssociationKey serialized?

[Emmanuel Bernard]

Hum, with the fact that this object now points to metadata, I wonder if
we should force EhCache, Map and Infinispan to have their own version of
EntityKey / RowKey and AssociationKey (or an appropriate externalizer).

Emmanuel

On Mon 2014-02-03 11:56, Gunnar Morling wrote:
> Hi,
> 
> I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
> Serializable. When is it actually serialized?
> 
> I'm suspecting the answer is "never", as the type of the "metadata" member
> is not serializable, so I'd expect a NotSerializableException to be raised.
> 
> If so, does anything speak against making AssociationKey not implement
> Serializable?
> 
> 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 depending on ORM 4.3

[Emmanuel Bernard]

On Sat 2014-02-01 18:47, Sanne Grinovero wrote:
> On 27 January 2014 10:32, Gunnar Morling  wrote:
> > Looking at the issues which have been addressed or are work in progress
> > since the last release [1] I don't think we need a tag.
> 
> +1 especially as I understand JPA 2.1 is backwards compatible

It is not for containers and the app stack you use in general.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] OGM depending on ORM 4.3

[Emmanuel Bernard]

On Mon 2014-02-03 14:58, Sanne Grinovero wrote:
> On 3 February 2014 13:34, Emmanuel Bernard  wrote:
> > On Sat 2014-02-01 18:47, Sanne Grinovero wrote:
> >> On 27 January 2014 10:32, Gunnar Morling  wrote:
> >> > Looking at the issues which have been addressed or are work in progress
> >> > since the last release [1] I don't think we need a tag.
> >>
> >> +1 especially as I understand JPA 2.1 is backwards compatible
> >
> > It is not for containers and the app stack you use in general.
> 
> haa, right.
> What do you have in mind specifically? Like an JBossAS 7.1 wanting to use OGM 
> ?
> 
> I'm sure we could make modules for it, for Hibernate (native API)
> users, but I don't know how it would work as a JPA provider.

I am preparing for adoption. So any container really (Weblo, Websphere, Tomcat,
TomEE, Spring x.y etc etc).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0

[Emmanuel Bernard]

Resending as I screwed up the Hibernate Dev email.

On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
> Hello Hardy, Sanne and all,
> 
> I think it's time to discuss the schedule we want for Hibernate Search
> 5. While we don't usually use time boxing, it's still useful to try and
> shoot for a rough capped timing.
> 
> I have proposed several options for the meeting on Doodle, make sure to
> set the time zone correctly.
> 
> http://doodle.com/8mfadig97447bb4s#table
> 
> Anyone is welcome to join of course and we will try to accommodate for
> most. But the propose schedules tend to be European friendly and if
> possible I'd love to get this meeting done by Wed.
> 
> Emmanuel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HSEARCH Discussions on schedule for Hibernate Search 5.0

[Emmanuel Bernard]

This is Tuesday 4 (tomorrow) from 16:30 to 17:30 CET. Everyone's invited :)

Ps: I thought I was to blame for freenode issues but apparently no :)

> On 3 févr. 2014, at 20:01, Sanne Grinovero  wrote:
> 
> If IRC doesn't work at the selected time, let's use:
> https://gitter.im/hibernate/hibernate-search
> 
>> On 3 February 2014 15:17, Emmanuel Bernard  wrote:
>> Resending as I screwed up the Hibernate Dev email.
>> 
>>> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
>>> Hello Hardy, Sanne and all,
>>> 
>>> I think it's time to discuss the schedule we want for Hibernate Search
>>> 5. While we don't usually use time boxing, it's still useful to try and
>>> shoot for a rough capped timing.
>>> 
>>> I have proposed several options for the meeting on Doodle, make sure to
>>> set the time zone correctly.
>>> 
>>> http://doodle.com/8mfadig97447bb4s#table
>>> 
>>> Anyone is welcome to join of course and we will try to accommodate for
>>> most. But the propose schedules tend to be European friendly and if
>>> possible I'd love to get this meeting done by Wed.
>>> 
>>> Emmanuel

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

Re: [hibernate-dev] Feature Proposal for Hibernate Search

[Emmanuel Bernard]

Hi Martin,

That's interesting. I have a couple of questions for you.

What is the notion of profile and when would you use it?

When do you need and use sub query ids?

The issue you had was to map getters to query parameters in an easier way than 
currently possible, correct? It reminds me a little bit of the Example query 
with a parameter twist. 

I have to admit, I am a bit skeptical on a few things:
- having to extend a technical class
- I don't think annotations are the best way to express queries but you 
probably have your reasons, so let's discuss them :)

Have you explored the ability to write the query programmatically while still 
making use of the getter binding? I can imagine we could update the DSL to 
accept the parameters holder and have them injected. 

I wonder if literally an Example API would address your use cases ?

Thanks the first thoughts

Emmanuel

> On 3 févr. 2014, at 19:08, Martin Braun  wrote:
> 
> 
> Hi,
> 
> 
> I am currently working on a new way to query in Hibernate Search. It's not 
> finished, but
> it already works. I am planning on extending the functionality a lot in the 
> future and
> I thought this could be a nice addition to Hibernate Search. What do you 
> think?
> 
> 
> https://github.com/s4ke/HibernateSearchQueryExtension
> 
> 
> Martin Braun
> martinbraun...@aol.com
> www.github.com/s4ke
> 
> ___
> 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] When is AssociationKey serialized?

[Emmanuel Bernard]

> On 3 févr. 2014, at 15:21, Sanne Grinovero  wrote:
> 
>> On 3 February 2014 13:33, Emmanuel Bernard  wrote:
>> Hum, with the fact that this object now points to metadata, I wonder if
>> we should force EhCache, Map and Infinispan to have their own version of
>> EntityKey / RowKey and AssociationKey (or an appropriate externalizer).
> 
> Ok to consider it, but let's keep an eye on performance requirements:
> allocating twice the objects which are strictly necessary is probably
> not going to help.
> Maybe if these where interfaces, each GridDialect could make his own type ?
> 

The thing is only the key/value dialects do make use of the keys objects. And 
even in that case, it might not make sense to actually reuse these objects. For 
example if the cache name is the table and only the id columns are part of the 
key.
Is that edge case worth this complexity (interfaces and splitting the 
metadata)? Maybe with optional methods in the grid dialect? That would still 
make me sad I guess :)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Feature Proposal for Hibernate Search

[Emmanuel Bernard]

The example API I was thinking about is
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#querycriteria-examples

> On 3 févr. 2014, at 21:57, Martin Braun  wrote:
> 
> HI Emmanuel,
> Hi Martin,
> 
> > That's interesting. I have a couple of questions for you.
> > What is the notion of profile and when would you use it?
> This can be used when you'd like to be able to use the same queryBean in 
> different contexts
> sou you don't have to write a different Bean if you only need a query that's 
> a little bit different.
> > When do you need and use sub query ids?
> This is needed if you want to do queries like this (explained in 
> boolean-logic):
> (queryA && (!queryB || queryC)).
> You can get as complicated as you want with this. These SubQueries are mainly 
> used because
> Java doesn't allow recursiveness in Annotations.
> > The issue you had was to map getters to query parameters in an easier way 
> > than 
> > currently possible, correct? It reminds me a little bit of the Example 
> > query 
> > with a parameter twist. 
> Which one are you talking about?
> > I have to admit, I am a bit skeptical on a few things:
> > - having to extend a technical class
> I am too, As stated in the e-mail before I want to get away from that design 
> but I still
> want to be able to write queries myself if I want to. This can be done with 
> Annotations on
> Method-Level or with QueryProviders in an extra Annotation on the Type-Level.
> > - I don't think annotations are the best way to express queries but you 
> > probably 
> > have your reasons, so let's discuss them :)
> Why? I think it's not hard to read an you have the query right with your 
> ParameterWrapper-class which holds your data.
> > Have you explored the ability to write the query programmatically while 
> > still 
> > making use of the getter binding? I can imagine we could update the DSL to 
> > accept the parameters holder and have them injected.
> I think that would be possible, but then you would still have to handle the
> query nesting and such by hand and that code would be more complicated to use 
> (but easier to debug, tbh).
> > I wonder if literally an Example API would address your use cases ?
> What do you mean by that?
> Martin Braun
> martinbraun...@aol.com
> www.github.com/s4ke
> 
> 
> -Original Message-
> From: Emmanuel Bernard 
> To: Martin Braun 
> Cc: hibernate-dev 
> Sent: Mon, Feb 3, 2014 9:45 pm
> Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
> 
> Hi Martin,
> 
> That's interesting. I have a couple of questions for you.
> 
> What is the notion of profile and when would you use it?
> 
> When do you need and use sub query ids?
> 
> The issue you had was to map getters to query parameters in an easier way 
> than 
> currently possible, correct? It reminds me a little bit of the Example query 
> with a parameter twist. 
> 
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
> - I don't think annotations are the best way to express queries but you 
> probably 
> have your reasons, so let's discuss them :)
> 
> Have you explored the ability to write the query programmatically while still 
> making use of the getter binding? I can imagine we could update the DSL to 
> accept the parameters holder and have them injected. 
> 
> I wonder if literally an Example API would address your use cases ?
> 
> Thanks the first thoughts
> 
> Emmanuel
> 
> > On 3 févr. 2014, at 19:08, Martin Braun  wrote:
> > 
> > 
> > Hi,
> > 
> > 
> > I am currently working on a new way to query in Hibernate Search. It's not 
> finished, but
> > it already works. I am planning on extending the functionality a lot in the 
> future and
> > I thought this could be a nice addition to Hibernate Search. What do you 
> think?
> > 
> > 
> > https://github.com/s4ke/HibernateSearchQueryExtension
> > 
> > 
> > Martin Braun
> > martinbraun...@aol.com
> > www.github.com/s4ke
> > 
> > ___
> > 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] Feature Proposal for Hibernate Search

[Emmanuel Bernard]

> On 3 févr. 2014, at 21:57, Martin Braun  wrote:
> > I have to admit, I am a bit skeptical on a few things:
> > - having to extend a technical class
> I am too, As stated in the e-mail before I want to get away from that design 
> but I still
> want to be able to write queries myself if I want to. This can be done with 
> Annotations on
> Method-Level or with QueryProviders in an extra Annotation on the Type-Level.

You lost me :)
Could you write some code, maybe in a gist.github.com ?

> > - I don't think annotations are the best way to express queries but you 
> > probably 
> > have your reasons, so let's discuss them :)
> Why? I think it's not hard to read an you have the query right with your 
> ParameterWrapper-class which holds your data.

Indeed I like that both the query and the parameter values are hosted on the 
same class. And I would have the programmatic query expressed on that class. (I 
know it goes against my later proposal to provide params support in the DSL 
itself but I explore multiple routes :) ). This also solves another problem we 
have today of propagating the entity type to the creation of the full text 
query. 

But annotations in my opinion don't scale very well for tree structures. 
Composition, lack of polymorphism are also not easy / elegant in annotations. 
You can see that you had to break the sub queries with string references. And I 
am not sure how you will be able to express other query types that we have like 
range, spatial etc. I might be wrong, so it's worth trying. But even then, if 
we had one new query type, we have to also add an equivalent annotation or add 
new fields to an existing one. 

> > Have you explored the ability to write the query programmatically while 
> > still 
> > making use of the getter binding? I can imagine we could update the DSL to 
> > accept the parameters holder and have them injected.
> I think that would be possible, but then you would still have to handle the
> query nesting and such by hand and that code would be more complicated to use 
> (but easier to debug, tbh).

What do you mean by query nesting by hand? And how does the annotation approach 
differs?

> > I wonder if literally an Example API would address your use cases ?
> What do you mean by that?
> Martin Braun
> martinbraun...@aol.com
> www.github.com/s4ke
> 
> 
> -Original Message-
> From: Emmanuel Bernard 
> To: Martin Braun 
> Cc: hibernate-dev 
> Sent: Mon, Feb 3, 2014 9:45 pm
> Subject: Re: [hibernate-dev] Feature Proposal for Hibernate Search
> 
> Hi Martin,
> 
> That's interesting. I have a couple of questions for you.
> 
> What is the notion of profile and when would you use it?
> 
> When do you need and use sub query ids?
> 
> The issue you had was to map getters to query parameters in an easier way 
> than 
> currently possible, correct? It reminds me a little bit of the Example query 
> with a parameter twist. 
> 
> I have to admit, I am a bit skeptical on a few things:
> - having to extend a technical class
> - I don't think annotations are the best way to express queries but you 
> probably 
> have your reasons, so let's discuss them :)
> 
> Have you explored the ability to write the query programmatically while still 
> making use of the getter binding? I can imagine we could update the DSL to 
> accept the parameters holder and have them injected. 
> 
> I wonder if literally an Example API would address your use cases ?
> 
> Thanks the first thoughts
> 
> Emmanuel
> 
> > On 3 févr. 2014, at 19:08, Martin Braun  wrote:
> > 
> > 
> > Hi,
> > 
> > 
> > I am currently working on a new way to query in Hibernate Search. It's not 
> finished, but
> > it already works. I am planning on extending the functionality a lot in the 
> future and
> > I thought this could be a nice addition to Hibernate Search. What do you 
> think?
> > 
> > 
> > https://github.com/s4ke/HibernateSearchQueryExtension
> > 
> > 
> > Martin Braun
> > martinbraun...@aol.com
> > www.github.com/s4ke
> > 
> > ___
> > 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 Discussions on schedule for Hibernate Search 5.0

[Emmanuel Bernard]

Turns out it conflicts with the other Hibernate general meeting on IRC. 
So we are moving it up 30 mins from 16:00 to 17:00 CET. 

> On 3 févr. 2014, at 20:58, Emmanuel Bernard  wrote:
> 
> This is Tuesday 4 (tomorrow) from 16:30 to 17:30 CET. Everyone's invited :)
> 
> Ps: I thought I was to blame for freenode issues but apparently no :)
> 
>> On 3 févr. 2014, at 20:01, Sanne Grinovero  wrote:
>> 
>> If IRC doesn't work at the selected time, let's use:
>> https://gitter.im/hibernate/hibernate-search
>> 
>>> On 3 February 2014 15:17, Emmanuel Bernard  wrote:
>>> Resending as I screwed up the Hibernate Dev email.
>>> 
>>>> On Mon 2014-02-03 14:28, Emmanuel Bernard wrote:
>>>> Hello Hardy, Sanne and all,
>>>> 
>>>> I think it's time to discuss the schedule we want for Hibernate Search
>>>> 5. While we don't usually use time boxing, it's still useful to try and
>>>> shoot for a rough capped timing.
>>>> 
>>>> I have proposed several options for the meeting on Doodle, make sure to
>>>> set the time zone correctly.
>>>> 
>>>> http://doodle.com/8mfadig97447bb4s#table
>>>> 
>>>> Anyone is welcome to join of course and we will try to accommodate for
>>>> most. But the propose schedules tend to be European friendly and if
>>>> possible I'd love to get this meeting done by Wed.
>>>> 
>>>> 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] Feature Proposal for Hibernate Search

[Emmanuel Bernard]

On Tue 2014-02-04  4:24, Martin Braun wrote:
>   /**
>* @return a custom sort object or null
>*/
>   public Sort getSort();
> 
> 
> or how to facet, etc...
> 
> 
> I want for this stuff to move to annotations (maybe) because I don't really 
> like
> the fact that I have to implement an Interface for that (and the current 
> approach doesn't
> allow profiles).

Here is an half formed alternative idea that reverts your model.

class SomeQuery {

// some params as getter / setters

@Query(profile="a", forEntity=Customer.class)
public Query query(QueryBuilder qb) {
return qb.bool()
.must(
qb.keyword()
.onField("name")
.boostedTo(2f)
.matchingParameter("name")
.createQuery();
).createQuery(); //some other boolean query should be here
}

@Sort(profile="a")
Sort getSort() { ... }

...
}

session.createFullTextQuery(someQuery).list();

What this achieved is:

- all query info in one class
- support for multiple profiles
- reuse existing programmatic API

Probably some kind of interface would make more sense to propagate the
return type.

> > But annotations in my opinion don't scale very well for tree structures. 
> > Composition, lack of polymorphism are also not easy / elegant in 
> > annotations. 
> > You can see that you had to break the sub queries with string references. 
> 
> 
> I think they don't scale well in the general case but in this scenario I 
> think it's ok.
> 
> 
> Look at this:
> 
> 
> 
> @Queries(@Query(profile = "notName", must = @Must(subQuery = 
> "someNameForTheQuery")))
> @SubQueries(@SubQuery(id = "someNameForTheQuery", query = @Query(must = 
> @Must(not = true, value = @SearchField(fieldName = "name", propertyName = 
> "name")
> 
> 
> 
> I look at it this way: I lose the easy way to do tree structures, but I gain 
> a way to document my query by having to give names to my sub-queries :).

I can document my subqueries by name using Java local variables :)

Query filterByName = 
qb.keyword().onField("name").matchingParameter("name").createQuery();
return qb.all().except(filterByName).createQuery();

BTW, I wonder why in your annotation approach all @Query are junction
queries. There is a small redundancy as the subquery defines a must not
in your example and the top query defines a must. What would happen if
the top query defined a @Should? Bootstrap error?
This is one of the things that throw off Hardy (I think) and me when we
look at the current annotations.

> 
> 
> > And I am not sure how you will be able to express other query types that we 
> > have like range, spatial etc. I might be wrong, so it's worth trying. But 
> > even then, if we had one new query type, we
> > have to also add an equivalent annotation or add new fields to an existing 
> > one. 
> 
> 
> 
> Uhm. I totally forgot to add this functionality in my rewrite (I have 
> rewritten most of the code last weekend)
> and I implemented a way to pass parameters into QueryTypes. You can even pass 
> parameters that are dynamically
> determined by stating the property to get its value from. With that you can 
> easily do RangeQueryTypes.
> If you want me to elaborate on that, I can provide you with an example.

Yes :)

> 
> 
> > What do you mean by query nesting by hand?
> 
> 
> Consider you have a query like this (again with boolean syntax):
> 
> 
> (queryA || queryD) && (queryB || (queryC) || queryE,...
> 
> 
> Now you would have to build a BooleanJunction and several subJunctions
> and then put them together. I have written that type of code before and
> I made some mistakes because I messed up the variable names in my head.
> 
> 
> > And how does the annotation approach differs?
> 
> 
> In the annotation Version it would look something like this (example from 
> above):
> 
> 
> 
> @Queries(@Query(must = {
>   @Must(subQuery = "queryAOrQueryD"),
>   @Must(subQuery = "queryBOrQueryC"),
>   @Must(subQuery = "queryE")}))
> @SubQueries({
>   @SubQuery(id = "queryAOrQueryD", 
>   query = @Query(should = {@Should(subQuery = "queryA"), 
> @Should(subQuery = "queryD")})
>   @SubQuery(id = "queryBOrQueryC",
>   query = @Query(should = {@Should(subQuery = "queryB"), 
> @Should(subQuery = "queryC")})
>   ...
>   //define query[A-E] here.
> })
> 
> 
> 
> Maybe it's because I don't like to work with the Junctions and put them 
> together myself,
> and maybe it's only me that thinks this would be easier :P.

OK. BTW this is how I would write such query decomposing it. I would not
rely on the intermediary BooleanJunction object.

Query queryA = ...
Query queryB = ...
Query queryC = ...
Query queryD = ...
Query queryE = ...

qb.bool()
.must(
qb.bool().should(queryA).should(queryD).createQuery()
   

Re: [hibernate-dev] API/SPI in 5.0

[Emmanuel Bernard]

I have looked at Search and identified the elements that use
Configuration and it's access to mapping.

During bootstrap via an Integrator, we use

Configuration.getProperties()
Configuration.getreflectionManager (optional)
cfg.getClassMappings()

The properties are used to bootstrap Hibernate Search as we receive our
properties form the Hibernate ORM configurations

The class mappings is necessary for us as it offers the list of entities
we need to look at. From them, we bootstrap with the subsection that are
@Indexed entities.
We do that by associating a SF Observer and passing in the Configuration
object and using the SF instance passed.
This observer is initialized by the Integrator.

>From what I understand the replacement for
Integrator.integrate(Configuration, SessionFactoryImplementor, 
SessionFactoryServiceRegistry)
is
Integrator.integrate(MetadataImplementor, SessionFactoryImplementor, 
SessionFactoryServiceRegistry)

How we get access to the properties and the list of mapped classes in
the new form?

Emmanuel

On Fri 2014-01-31 14:14, Steve Ebersole wrote:
> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI 
> methods that are no longer relevant.  I think it is better to look at 
> these individually.
> 
> == Configuration
> 
> I went ahead and made a preliminary decision here as I discussed in 
> HHH-7164.  The thinking is that we had some leeway here because 
> Configuration had been deprecated (and pretty widely known to be 
> deprecated based on StackOverflow and other sources).   Basically I made 
> Configuration a simple delegate to the new Metadata building code.  I 
> removed all the methods that exposed access to the org.hibernate.mapping 
> objects that Configuration used to manage.
> 
> ---
> 
> == Integrator
> 
> This one is a little tougher.  In retrospect I think I would have just 
> gone for a number of discrete contributor contracts.  For example, 
> usually Integrator is used to add event listeners, so an 
> EventListenerContributor would have worked.  Then I would have used 
> Integrator as a grouping of contributors.
> 
> 
> == PersisterFactory (and persister constructors)
> 
> Forms taking Configuration and org.hibernate.mapping objects should, 
> imo, get removed.  But I can live with deprecation if someone wants to 
> "pound the table" for that.  But realize that the 
> Configuration+org.hibernate.mapping forms would not be called ever.
> ___
> 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] API/SPI in 5.0

[Emmanuel Bernard]

For OGM the impact is less but in
Integrator.integrate
we use Configuration to be able to conditionally add a naming strategy 
configuration.setNamingStrategy().

Not sure what to do here either in the 
ntegrate(MetadataImplementor, SessionFactoryImplementor, 
SessionFactoryServiceRegistry)
case.

We don’t use PersisterFactory but rather override the PersisterClassResolver 
service.

Emmanuel

On 06 Feb 2014, at 13:46, Emmanuel Bernard  wrote:

> I have looked at Search and identified the elements that use
> Configuration and it's access to mapping.
> 
> During bootstrap via an Integrator, we use
> 
> Configuration.getProperties()
> Configuration.getreflectionManager (optional)
> cfg.getClassMappings()
> 
> The properties are used to bootstrap Hibernate Search as we receive our
> properties form the Hibernate ORM configurations
> 
> The class mappings is necessary for us as it offers the list of entities
> we need to look at. From them, we bootstrap with the subsection that are
> @Indexed entities.
> We do that by associating a SF Observer and passing in the Configuration
> object and using the SF instance passed.
> This observer is initialized by the Integrator.
> 
>> From what I understand the replacement for
> Integrator.integrate(Configuration, SessionFactoryImplementor, 
> SessionFactoryServiceRegistry)
> is
> Integrator.integrate(MetadataImplementor, SessionFactoryImplementor, 
> SessionFactoryServiceRegistry)
> 
> How we get access to the properties and the list of mapped classes in
> the new form?
> 
> Emmanuel
> 
> On Fri 2014-01-31 14:14, Steve Ebersole wrote:
>> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI 
>> methods that are no longer relevant.  I think it is better to look at 
>> these individually.
>> 
>> == Configuration
>> 
>> I went ahead and made a preliminary decision here as I discussed in 
>> HHH-7164.  The thinking is that we had some leeway here because 
>> Configuration had been deprecated (and pretty widely known to be 
>> deprecated based on StackOverflow and other sources).   Basically I made 
>> Configuration a simple delegate to the new Metadata building code.  I 
>> removed all the methods that exposed access to the org.hibernate.mapping 
>> objects that Configuration used to manage.
>> 
>> ---
>> 
>> == Integrator
>> 
>> This one is a little tougher.  In retrospect I think I would have just 
>> gone for a number of discrete contributor contracts.  For example, 
>> usually Integrator is used to add event listeners, so an 
>> EventListenerContributor would have worked.  Then I would have used 
>> Integrator as a grouping of contributors.
>> 
>> 
>> == PersisterFactory (and persister constructors)
>> 
>> Forms taking Configuration and org.hibernate.mapping objects should, 
>> imo, get removed.  But I can live with deprecation if someone wants to 
>> "pound the table" for that.  But realize that the 
>> Configuration+org.hibernate.mapping forms would not be called ever.
>> ___
>> 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] API/SPI in 5.0

[Emmanuel Bernard]

On 06 Feb 2014, at 14:52, Steve Ebersole  wrote:

> 
> On Thu, Feb 6, 2014 at 7:01 AM, Emmanuel Bernard  
> wrote:
> For OGM the impact is less but in
> Integrator.integrate
> we use Configuration to be able to conditionally add a naming strategy 
> configuration.setNamingStrategy().
> See this actually illustrates the problems with Configuration, so thanks for 
> that :).  Setting the naming strategy there would have had no effect because 
> its "too late in the game".  And there is really no corollary in the new code 
> because of that (setting the naming strategy is available earlier).
>  


You are right, it looks like we do set it in our custom persistence provider 
impl for JPA and in OgmConfiguration otherwise.
How can I set naming strategy in a transparent fashion to people in the new 
code way? OgmConfiguration will be gone in the new scheme.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] API/SPI in 5.0

[Emmanuel Bernard]

On 06 Feb 2014, at 15:10, Steve Ebersole  wrote:

> 
> On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard  
> wrote:
> 
> Configuration.getreflectionManager (optional)
> 
> We do not use commons-annotations anymore at all (yaay!).  If you need access 
> to this type of functionality, I have been thinking about passing along 
> access to the Jandex index we use.
> 
>  
> The properties are used to bootstrap Hibernate Search as we receive our
> properties form the Hibernate ORM configurations
> 
> Settings/configuration values are now available via either the SessionFactory 
> or the ConfigurationService (which just holds the settings and exposes them 
> in various type-safe ways).
>  
> 
> The class mappings is necessary for us as it offers the list of entities
> we need to look at. From them, we bootstrap with the subsection that are
> @Indexed entities.
> 
> "Mapping information" is MetadataImplementor.  Though tbh it sounds like you 
> really just want/need Jandex.

That’s all super useful. I’ve updated 
https://hibernate.atlassian.net/browse/HSEARCH-856 to track the necessary 
changes. It’s much less painful that I anticipated.

>  
> We do that by associating a SF Observer and passing in the Configuration
> object and using the SF instance passed.
> This observer is initialized by the Integrator.
> 
> I am not understanding this part at all.  Integrator is called during the 
> process of creating a SessionFactory, so I would think that the 
> sessionFactoryCreated callback would be moot here.  And you already have a 
> hook for a sessionFactoryClosed callback in Integrator#disintegrate.  So 
> you'll need to explain this some more.
> 
> Regardless, if you really really really want to use a SessionFactoryObserver 
> then you'd just call SessionFactoryImplementor#addObserver from your 
> Integrator

It is related to a recent change by Sanne and Hardy to have access to a fully 
initialized SessionFactory to bootstrap Hibernate Search I think. But they can 
tell more about this.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] API/SPI in 5.0

[Emmanuel Bernard]

On Thu 2014-02-06 21:52, Hardy Ferentschik wrote:
> 
> On 6 Jan 2014, at 15:10, Steve Ebersole  wrote:
> 
> > On Thu, Feb 6, 2014 at 6:46 AM, Emmanuel Bernard 
> > wrote:
> > 
> > Configuration.getreflectionManager (optional)
> >> 
> > 
> > We do not use commons-annotations anymore at all (yaay!).  If you need
> > access to this type of functionality, I have been thinking about passing
> > along access to the Jandex index we use.
> 
> >> The class mappings is necessary for us as it offers the list of entities
> >> we need to look at. From them, we bootstrap with the subsection that are
> >> @Indexed entities.
> >> 
> > 
> > "Mapping information" is MetadataImplementor.  Though tbh it sounds like
> > you really just want/need Jandex.
> 
> +100 I think it might be time to address 
> https://hibernate.atlassian.net/browse/HSEARCH-1213
> and get rid of commons annotations and just consume the Jandex index resp. 
> build our own.
> 
> The bigger road block for this atm is the programmatic configuration which 
> uses the proxy 
> annotations approach from commons annotations. However, with the new 
> metamodel we have
> we should be able to instantiate the model classes directly and skip the 
> whole proxy business.

Which metamodel, the ORM one? Hibernate Search doesnot / cannot depend on ORM 
for
that part (the programmatic API). Only the orm module can.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] API/SPI in 5.0

[Emmanuel Bernard]

On Thu 2014-02-06 21:08, Emmanuel Bernard wrote:
> 
> On 06 Feb 2014, at 14:52, Steve Ebersole  wrote:
> 
> > 
> > On Thu, Feb 6, 2014 at 7:01 AM, Emmanuel Bernard  
> > wrote:
> > For OGM the impact is less but in
> > Integrator.integrate
> > we use Configuration to be able to conditionally add a naming strategy 
> > configuration.setNamingStrategy().
> > See this actually illustrates the problems with Configuration, so thanks 
> > for that :).  Setting the naming strategy there would have had no effect 
> > because its "too late in the game".  And there is really no corollary in 
> > the new code because of that (setting the naming strategy is available 
> > earlier).
> >  
> 
> 
> You are right, it looks like we do set it in our custom persistence provider 
> impl for JPA and in OgmConfiguration otherwise.
> How can I set naming strategy in a transparent fashion to people in the new 
> code way? OgmConfiguration will be gone in the new scheme.

I have been thinking about it more.
Assuming we don't want to create specific subclasses in the new approach
like we did with OgmConfiguration, we will need to ask the user to
express the fact that he wants to use OGM instead of ORM. This could be
by adding a specific property, adding a specific service in the registry
etc.

With that flag, we then need to do a few checks and set a few options:

- set a naming strategy
- set a datasource name (that might change with the new code but was required
  to avoid an error before)
- set an identifier generator strategy provider
- use the new id generator mappings
- disable query startup checking (until we have a hook to add our own
  native query syntax checking logic)
- set some Hibernate Search properties

So it seems that from a property or service set by the user, OGM needs
to be able to set a few properties and options (see above)
transparently. And from what Steve says, it has to be done very early
on.

I would love a centralize approach somewhat tied to Integrator. The
alternative is a nasty static method accepting the Hibernate ORM
bootstrap objects and modify them. But then the user has to call this
static method :(

//some signature like that I suppose, not really expert in the new
//bootstrap approach
static MetadataBuilder enableOGM(ServiceRegistry registry, MetadataSources 
metadataSources) { ... }

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

[hibernate-dev] Where to host dtd, xsd files?

[Emmanuel Bernard]

Simply add the files to hibernate.org's repository.
Hardy did it for dtds 
https://github.com/hibernate/hibernate.org/tree/production/dtd

The files will be published.

Emmanuel
___
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

[Emmanuel Bernard]

On Mon 2014-02-10 11:50, 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
> ...

I am fine with it. I think I like it more actually as it makes writing a
new datastore easier and more isolated.
A bit harder on the user, but nothing earth shaking.

> 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 :)

I could agree with myself quite well :)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] When is AssociationKey serialized?

[Emmanuel Bernard]

> >> The thing is only the key/value dialects do make use of the keys objects.
> >> And even in that case, it might not make sense to actually reuse these
> >> objects. For example if the cache name is the table and only the id columns
> >> are part of the key.
> >> Is that edge case worth this complexity (interfaces and splitting the
> >> metadata)? Maybe with optional methods in the grid dialect? That would 
> >> still
> >> make me sad I guess :)
> 
> Actually these keys where originally designed to be the keys in
> key/value stores and the cost of not reusing them is high, so I'm not
> following why you would like to make them not Serializable; indeed
> some have some fields which need to be moved out, but there are JIRA's
> open for that already as it's an important consideration for storage
> size -> memory consumption: OGM-151
> 
> I'm not sure I understood what you are suggesting we could do when the
> "cache name is the table and only the id columns are part of the key":
> to use just the array for the key? Sadly we need to override equals of
> the array, so at least one wrapper is needed (unless we find a way to
> override comparisons in Infinispan and all others). But a second
> wrapper is simply "one too much" because conceptually we don't need
> it.

Sanne and I took the conversation online and we could only agree that
the other one was crazy.
But we also agree that making AssociationMetadata Serializable was
cheap. Hopefully we won't regret that contract enhancement.

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