Allowing "getListeners" method in ThreadLocal wrapped Sessions
by Sanne Grinovero
Hello All,
when binding the Session to a thread (when using
org.hibernate.context.ThreadLocalSessionContext) it is currently
mandatory to start a transaction before any use of the session, this
includes currently Search.getFullTextSession, mandatory in order to
use Hibernate Search, as it uses getListener().
This behaviour was introduced since Search 3.1.1 to prevent other
trouble with code forgetting to start a transaction it will use
session.getListeners() as soon as the user calls getFullTextSession
(HSEARCH-178, which is a workaround for HHH-2763)
The method "getListeners" is not in the whitelist of allowed methods
on the session; could this be added?
I'm referring to the private class TransactionProtectionWrapper in
org.hibernate.context.ThreadLocalSessionContext, around line 330.
Could this also be applied to 3.3.x branch? it would help users of
Search using these core versions, while having no effect impact on
others uses.
Regards,
Sanne
15 years
Hibernate as a persistence engine
by Adam Warski
Hello,
I took a look at the new meta-model proposed by Steve; in case anybody hasn't seen it it's here:
http://anonsvn.jboss.org/repos/hibernate/sandbox/trunk/new-metadata/
If I correctly understood Steve and the code, the model builds on the JPA2 meta-model. In the proposition there are three levels of meta-data:
1) database
2) mapping
3) java
However as Steve mentioned on IRC, there is a problem with alternate entity modes (today these are "map" and "xml").
(For me they are very useful, as Envers uses the "map" entity mode to dynamically generate the audit entities.)
Don't you think that an "entity" meta-data level would be useful?
The basic layers would then be:
1) database - information about tables, columns, foreign keys, indexes
2) mapping - binding between levels 1 and 3, that is, assignment from properties to columns, from entities to tables etc
3) entity - information about entity names, property names, property types (a property can be a simple value, many-to-one, one-to-many, (...) relation, a component etc). For example, a many-to-many relation property would have no idea that it's mapped using a join table.
Now there could be several layers that build on that. Each such layer would have to specify what is an entity and what is a property; how to get/set a property from an entity; how to read other meta-data (from annotations? or from xml?)
4a) java - an entity is a class; holds information if properties are accessed using fields or getters/setters
4b) map - an entity is a map; properties accessed using Map.get()
4c) xml
In the longer run, maybe Hibernate could become more of a "persistence engine".
That is, it would provide a nice entity abstraction of a database (so abstracting level 1 using level 3 as the access point).
It would play nicely with another project that I have in mind, namely an ORM for Scala that would use Hibernate. Only a new entity mode (level 4) would have to be written, which would be a translation from Scala constructs to entities, properties, relations. (Maybe that would even be something that Bob could use in TorqueBox.)
What do you think?
--
Merry Christmas! :)
Adam
15 years
Testing database objects
by Emmanuel Bernard
I've added a trivial 2 methods helper class to help discover if a table name is present in the configuration, a table + column name is present in the configuration.
If you need such checking, check out in HANN SchemaUtil.
15 years
Missing setLoadedPersister() and this.loadedKey = loadedKey in CollectionEntry constructor ?
by Florent Bayle
Hi,
While testing one of our app, I found a problem : after saving a pojo
with a new HashSet, the saved pojo PersistentSet role/key were null.
I tracked the problem down to one of the CollectionEntry constructors:
public CollectionEntry(CollectionPersister persister,
PersistentCollection collection).
It seems that in this constructor, setLoadedPersister(loadedPersister)
isn't called, nor this.loadedKey = loadedKey, contrary to the other
constructors.
Thus, when collection.setSnapshot(loadedKey, role, snapshot) is
called at the end of the constructor, role and loadedKey are null and
so, the PersistentSet role/key are null.
Is there a reason for that, and is it possible to patch it ?
Thanks.
--
Florent Bayle
15 years
