Configuration as data for generating metamodel
by Gail Badner
I've been thinking about how we can have the metamodel API in place in time for the 4.0.0.beta1.
One alternative is to use a fully built o.h.cfg.Configuration to provide the data for generating the new metamodel.
This is obviously not what we would want in the end, but in the near term it would give us the data with everything already resolved.
It would be available sooner so Steve could get going more quickly on building the SessionFactory/persisters.
I've thought of 2 ways we could use the Configuration:
1) create a separate type of metamodel source for Configuration data (e.g., org.hibernate.metamodel.source.configuration) and use data from this source to generate the metamodel.
2) use Configuration for binding missing data (what we haven't finished) from annotations and hbm sources; as more data is available, we can remove the references to Configuration.
Comments?
Gail
12 years, 11 months
Clarification of Attribute/Value bindings
by Gail Badner
In the new metamodel code, it appears that both "Attribute" and "Value" bindings are modelled using AttributeBinding. The places I've seen references to "Value" bindings (EntityIdentifier, Discriminator) don't necessarily have a domain representation.
I'm working on @IdClass, and this an example where the IdClass itself does not have a representation in the domain model.
I'd like to make some improvements.
Steve, (and anyone else interested) please take a look at https://gist.github.com/981804 and let me know if you see anything inherently wrong with my approach, or if you have some suggestions.
Thanks,
Gail
12 years, 11 months
summary of our brainstorming about mapping associations on OGM
by Sanne Grinovero
OGM is ongoing some refactoring around the associations mapping to be
able to provide similar locking and isolation experience as when using
a traditional database.
An association is mapped as tuples, which represent the columns on the
relational database (the association table);
So each association is identified by :
[tableName - FKcolumnName - FKcolumnValue]
and the value should "point to" the tuples.
In case the association is represented by a List of Set, then the
association table will have primary keys which prevents duplication of
entries:
- this set of primary keys is going to be the key of the
FineGrainedLockingAtomicMap[1]
- the elements of the touple not being part of the PK will be the
value used for the same FGLAM
- by the semantics of FGLAM, this means we can effectively modify the
elements which are identified by the PK, and acquire a lock only on
those "rows", effectively implementing the desired locking.
- identifying which elements are part of the PK and which are not can
be done at boot time, when figuring the "schema" of the database; it
depends on the kind of relation.
In case we're mapping a Bag, then it seems that we have no alternative
than to lock the whole set of values: as implementation we could use
the existing AtomicMap API from Infinispan.
one new thought:
- the core reference suggests that adding to a Bag can be quite
efficient as it doesn't need a return value. thinking about that, it
seems possible that the Bag modification doesn't need an eager lock.
In all cases, we're going to use custom types to represent the keys,
so that we can be flexible in changing it and write custom
Externalizers.
Basically, it will take some more time before this is implemented;
some drafts of the previous ideas (now deprecated) can be found at:
https://github.com/emmanuelbernard/hibernate-ogm/tree/atomicmap
[1] - as https://issues.jboss.org/browse/ISPN-1115
Cheers,
Sanne
12 years, 11 months
api/spi/internal package split
by Steve Ebersole
OK, now that we have been doing this for a few months and have some actual
experience, I wanted to circle back and talk about this notion of splitting up
packages to denote api/spi/internal intent.
Not so much "should we do it". I think we absolutely should to help do osgi
stuff a little later and now (new major rev) is the time to be changing up
packages.
Not, more I mean the specifics of how we will do this. Currently we took the
approach (mostly) that these distinctions are leaves (as in plural leaf) in
the package name. So for example, we have:
1) org.hibernate.service (api)
2) org.hibernate.service.spi
3) org.hibernate.service.internal
On the plus side this keeps related stuff grouped together. Everything under
org.hibernate.service we know relates to the notion of services. Everything
under org.hibernate.engine we know deals with the internal engine. etc
On the downside (imo) this creates lots of packages. To see what I mean, just
take a look at https://github.com/hibernate/hibernate-
core/tree/master/hibernate-core/src/main/java/org/hibernate/service
The only other option I saw was to make api/spi/internal the top level
packaging construct:
1) org.hibernate.service (still api)
2) org.hibernate.spi.service
3) org.hibernate.internal.service
What's been everyone's experience(s) here?
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
12 years, 11 months
Hibernate 4.0 logging looks too verbose still (suggest changing more info to debug/trace)
by Scott Marlow
Hi,
The following Hibernate log output is from running the AS 7.0
integration testsuite (with Hibernate 4.0.0.Alpha3)
http://pastie.org/1899179
I think some of the warnings might be telling me that we have something
wrong in the AS7/Hibernate integration. For example "23:43:42,001 WARN
[org.hibernate.ejb.AbstractEntityManagerImpl] (RMI TCP
Connection(2)-127.0.0.1) HHH00326:Cannot join transaction: do not
override hibernate.transaction.factory_class". If so, we should fix the
problem.
I think it would be in the spirit of our logging guideline
http://community.jboss.org/wiki/HowtologinJBossprojects, to move some of
the (non-critical) INFO messages to DEBUG or TRACE.
No one has disagreed about this in the past and many messages have
already changed. I wanted to see if we agree that more INFO messages
should be changed to DEBUG/TRACE.
For example, I think that we should use debug/trace level for indicating
when a connection is obtained/released (since that is a normal operation
that means that stuff is working).
Scott
12 years, 11 months
Re: [hibernate-dev] Hibernate OGM
by Alex Snaps
Unintentionally left the ML out.
Sanne, wrt jsr107 fair enough. I then feel that we should not leverage Map and use a custom type that only declare what's needed (and avoids the return value, when not required). I think that'd make it simpler, wdyt ? How should we name that thing ? My first attempt was GridMap...
On Wednesday 11 May 2011 at 16:50, Sanne Grinovero wrote:
> 2011/5/11 Alex Snaps <alex.snaps(a)gmail.com>:
> > On Wednesday 11 May 2011 at 15:38, Sanne Grinovero wrote:
> > Hi Alex,
> > > thank you I'm having a look and will comment more on github directly.
> > I'll look into your comments and will adapt. thanks!
> >
> > >
> > > A first comment: I see that a big part of your patch is about
> > > replaceing "Cache" with "ConcurrentMap" and renaming variables to be
> > > consistent with this change; at the same time in the JSR-107 forum it
> > > seems that everybody is agreeing on *not* extending Map, while there's
> > > going to be something similar to a Map, this is going to be called
> > > "Cache", so I'd stick with our current name.
> > > I understand this is a bit in flux now and nothing is cast in stone,
> > > but at the moment it would be better to keep your patch smaller and
> > > avoiding these conversions, or at least keeping these refactorings as
> > > a separate commit.
> >
> > I think that makes sense, I actually started with neither Map nor ConcurrentMap, but some other random Grib interface.
> > I then saw the wiki page mentioning Map... I certainly can review this, but it does look like the plan is to have this tailored to jsr-107, I didn't know that. I'll stick to ConcurrentMap return values, but will not rename further.
>
> Sorry I didn't mean to state that we're going to support jsr-107, we
> should discuss that but it's unlikely in practice as we want to
> support more alternatives than key/value stores.
> I'm only mentioning it as the abstraction you're introducing now will
> make OGM support only Infinispan and EHCache, and they happen to have
> this common API which gives names the building blocks as "Cache" and
> "CacheManager". So for the time being there's no need to change all
> variable names. It will definitely be more complex when other storage
> engines will be added; it might be an option to use JSR-107 or JSR-347
> at least for the key/value implementors but I don't think either is
> going to cover all of noSQL.
> Also even if we wanted to finish only Infinispan and EHCache, I don't
> think the ConcurrentMap API would be good enough, we likely need a
> more intrusive definition of "dialect" here.
>
>
> > > The plan is to build the first version of queries on top of Hibernate
> > > Search, so basically that's already an abstraction on top of any "Grid
> > > implementation" and it should work fine with EHCache as well; Lucene
> > > won't be able to solve all use cases though so for some cases we'll
> > > need to tap into special functionalities offered by the grid provider,
> > > but that's going to be a second step. Suggestions welcome of course!
> > I have seen that Hibernate Search approach, I wondered whether a real query bridge to the grid wouldn't make more sense. But I totally agree that that approach makes total sense as a first step.
> >
> > >
> > > As far as the "skip locking" pattern, that's currently the way to
> > > build a sequence generator on top of Infinispan, in case of EHCache
> > > you might want to suggest a totally different approach, I'd expect
> > > that this should be an implementation detail at the dialect level, not
> > > necessarily common code.
> > Alright, that makes sense as well... I'll look into abstracting that nicely behind the Dialect then.
> >
> > >
> > > Regards,
> > > Sanne
> > >
> > >
> > > 2011/5/11 Alex Snaps <alex.snaps(a)gmail.com>:
> > > > Hey,
> > > > I've taken some time and, in an attempt to port Hibernate OGM to use Ehcache instead of Infinispan, abstracted it from Infinispan.
> > > > As the doc on that task states, I've made all calls use ConcurrentMap (rather than Map actually). I had a little trouble understanding the "Skip locking proposed by Sanne" in OgmTableGenerator.doWorkInCurrentTransactionIfAny, so that this does a simple Map.get now (that might have been a specialization for a Dialect, but couldn't understand what it was all about).
> > > > And finally introduced a new hibernate.grid.manager prop to instantiate the proper provider...
> > > >
> > > > The changes are available here:
> > > > https://github.com/alexsnaps/hibernate-ogm/commit/d0fcbffed4c4bcc2aa5208c...
> > > >
> > > > Hope that can be made useful… I also wanted to start looking into queries next. But I'll send another mail on that later.
> > > > Thanks,
> > > > Alex
> > > >
> > > >
> > > > --
> > > > Alex Snaps <alex.snaps(a)gmail.com>
> > > > Senior Software Engineer - Terracotta
> > > > http://twitter.com/alexsnaps
> > > > http://www.linkedin.com/in/alexsnaps
> > > >
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
12 years, 11 months
providing AnalyzerUtils in Hibernate Search
by Sanne Grinovero
We're using AnalyzerUtils in some of the tests in Hibernate Search,
but I'm finding myself recommending people to "write something like
that" quite often lately, it seems that otherwise people have an hard
time to figure if their analyzer definitions make any sense.
What do you think in moving this class into the main jar, polish the
javadoc a bit and add a note on how to check your analyzer in the
docs?
Sanne
12 years, 11 months
Re: [hibernate-dev] Hibernate Search 3.5 or 4
by Sanne Grinovero
Hello,
To conclude this thread, there are still three notes "being discussed"
on the wiki:
http://community.jboss.org/wiki/PlansforHibernateSearch4
1) assume exclusive_index_use=true as default
That was my proposal, I'm not sure we're all agreeing on that.
Emmanuel was concerned for the index safety but I replied that it
doesn't remove locking.
2) Make it possible to configure different backends per index (there
can currently be only one backend
Another proposal, the wiki points out the 3 main reasons to do that:
* tune different backends for different purposes
* make it possible to have sync / async on different entities/indexes.
* use different clustering/replication options or even
technologies per index
3)Service instances
for the public extensions points sometimes it's useful to pass
instances instead of mere classnames to a SearchConfiguration
* Infinispan Query would love it to pass a self-built Directory
factory so that Search could use that to store indexes on the same
Infinispan instance (instead of starting a second cluster).
So if we clarify this plan I'd like to start filling up JIRAs, we can
then mark the most urgent ones for the next alpha and try making a
plan.
We especially need to coordinate on some of the issues, as if one of
us is going to change all package names while the other rewrites the
indexmanager, that creates some work we could avoid.
Sanne
12 years, 11 months
