> Only the CouchDB provider in the PR so far. But the idea is to move all
to that model.
Right; I've a local branch where I had started with @AssociationStorage
support for MongoDB, but focused on CouchDB then.
On a related note, Emmanuel raised the question whether to use the same
option types f
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 s
My opinion is that each provider "provides" its own set of options. If some
of them exist in multiple providers they should have the name so we won't
disturb users.
My 2 cents :)
Guillaume
2013/12/16 Gunnar Morling
> > Only the CouchDB provider in the PR so far. But the idea is to move all
> t
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/B
2013/12/16 Guillaume SCHEIBEL
> My opinion is that each provider "provides" its own set of options. If
> some of them exist in multiple providers they should have the name so we
> won't disturb users.
>
Just to be sure, did you mean to say "... should have the *same* name..."?
Note that the mot
> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.
I agree with emmanuel on this one.
I think I would be surprise to see that the annotation
Hi Ales,
thanks for the heads up, I wasn't aware it was already included in
WildFly so quickly.
Could we please include at least a single smoke test in it? Hibernate
Search 4.4 is NOT compatible with the ORM version currently in WF8, so
I don't think this was ever tried (other than via the Infinis
How does this relate to the "JBoss Modules" module provided by HSEARCH
itself?
>From a quick look it seems that WF provides now its own module for
hibernate-search-engine, the module.xml contents differ a bit from the one
in HSEARCH, though. Also the module paths are different, so a user putting
t
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
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
> How does this relate to the "JBoss Modules" module provided by HSEARCH itself?
Afaik, Paul and me weren't aware you had anything supported in HS.
> From a quick look it seems that WF provides now its own module for
> hibernate-search-engine, the module.xml contents differ a bit from the one in
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. Oper
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 Ju
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
Infinispan Subsystem supported Indexing element.
This then needed Query on the classpath to work properly.
(it could be hacked, ignored, but we opted not to do this)
Then with a "little" help from CapeDwarf team,
all "needed" libraries / modules were added.
Current module config (module.xml files
I've this feeling that this decision was rushed, there are several
implications for which we didn't prepare for.
I remember chatting with Paul Ferraro about the problem that the
Infinispan subsystem was needing to parse the "indexing" attribute
because of CapeDwarf's need to enable it, and that mor
I didn't know about this change either. Are there any WildFly unit
tests using HS?
On 12/16/2013 09:16 AM, Ales Justin wrote:
> Infinispan Subsystem supported Indexing element.
> This then needed Query on the classpath to work properly.
> (it could be hacked, ignored, but we opted not to do this
I would say you can always make changes, since afaik, nothing currently
directly depends on HS.
But having this in WF, is imo, good.
As this makes it super trivial / easy to use it.
And if there are multiple apps using it, you save on resources as well.
On 16 Dec 2013, at 16:18, Sanne Grinovero
Probably waiting on you or Sanne to add them. :-)
We're already running whole CapeDwarf Testsuite on it,
which means it's tested a lot -- 1300+ tests.
But of course, that doesn't mean you shouldn't have basic / smoke tests in WF.
;-)
On 16 Dec 2013, at 16:24, Scott Marlow wrote:
> I didn't kn
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)
> @Sto
2013/12/16 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
> > >
> >
On 12/16/2013 11:19 AM, Ales Justin wrote:
> Probably waiting on you or Sanne to add them. :-)
>
> We're already running whole CapeDwarf Testsuite on it,
> which means it's tested a lot -- 1300+ tests.
>
> But of course, that doesn't mean you shouldn't have basic / smoke tests in
> WF. ;-)
Do the
Just a quicks heads up about some work Gail and I will be doing in the
ORM repo today. Mainly the time has come to transition (back) to 5.0
development. We have submitted our passing JPA 2.1 TCK results to
Oracle, but are still awaiting response back from them; once we get
approval from them,
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
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 m
JPA 2.1 support is final. With 4.3.0.Final Hibernate is now a certified
implementation of the JPA 2.1 specification.
http://in.relation.to/Bloggers/HibernateORM430FinalRelease
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.j
I finished getting the 4.3 branch created, 4.3 Final tagged/released
and the work on master CR2..HEAD ported.
Unfortunately I messed up the last part. And the way I messed it up
makes it look like 4.3 Final includes CR2..HEAD, but it certainly does
not (the tag does, but I mean the released ar
Congratulations! That's a very significant one :-)
On 16 December 2013 22:49, Steve Ebersole wrote:
> JPA 2.1 support is final. With 4.3.0.Final Hibernate is now a certified
> implementation of the JPA 2.1 specification.
>
> http://in.relation.to/Bloggers/HibernateORM430FinalRelease
> __
+1
2013/12/17 Sanne Grinovero
> Congratulations! That's a very significant one :-)
>
> On 16 December 2013 22:49, Steve Ebersole wrote:
> > JPA 2.1 support is final. With 4.3.0.Final Hibernate is now a certified
> > implementation of the JPA 2.1 specification.
> >
> > http://in.relation.to/Bl
29 matches
Mail list logo
