Hibernate OGM: Multi-Tenancy?
by Sanne Grinovero
As I'm upgrading the Hibernate OGM -> Hibernate Search integration,
the new Search SPI explicitly demands a tenant-id on work
construction.
I suspect more work will be needed for multi-tenancy (at least some
tests) so I've opened OGM-821.
Might not be too complex? I suspect query results already respect the
restrictions.
I don't think multi-tenancy should be a very high priority for OGM,
but if this could pave the road to multiple-storage (different kinds)
.. now that would be really interesting.
Sanne
11 years
Forum down
by Gunnar Morling
Hi,
Accessing https://forum.hibernate.org/ gives me an error:
SQL ERROR [ mysql4 ]
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2) [2002]
Could someone with the right credentials take a look into this?
Thanks,
--Gunnar
11 years
Removing deprecated methods from Session and SessionFactory
by Gunnar Morling
Hi,
There are several deprecated methods on Session:
* public Object load(Class theClass, Serializable id, LockMode lockMode)
* public Object load(String entityName, Serializable id, LockMode lockMode);
* public void lock(Object object, LockMode lockMode);
* public void lock(String entityName, Object object, LockMode lockMode);
* public void refresh(Object object, LockMode lockMode);
* public Object get(Class clazz, Serializable id, LockMode lockMode);
* public Object get(String entityName, Serializable id, LockMode lockMode);
and SessionFactory:
* public void evict(Class persistentClass) throws HibernateException;
* public void evict(Class persistentClass, Serializable id) throws
HibernateException;
* public void evictEntity(String entityName) throws HibernateException;
* public void evictEntity(String entityName, Serializable id) throws
HibernateException;
* public void evictCollection(String roleName) throws HibernateException;
* public void evictCollection(String roleName, Serializable id) throws
HibernateException;
* public void evictQueries(String cacheRegion) throws HibernateException;
* public void evictQueries() throws HibernateException;
The docs point to methods to be used alternatively, so the upcoming ORM 5
major release seems like a good occasion to remove these methods and
simplifying these contracts a bit. Any thoughts?
On a related note, I am wondering whether
Session#public Object get(Class clazz, Serializable id, LockOptions
lockOptions);
etc. pull their weight. The same could be achieved via
byId( entityClass ).with( lockOptions ).load( id )
Is it actually worth to have these "shortcut" methods?
--Gunnar
11 years
Hibernate Search 5 compatible with Hibernate ORM 4?
by Sanne Grinovero
Just a heads up: I'm not seeing the question from the subject often enough.
In fact, I only see it when I suggest to upgrade when helping some
user. It's like they are very surprised "no way, I didn't think that
was possible?!"
I think I've been hammering this information in each and every release
blog, but apparently an assumption on major versions needing to be
aligned is stronger.
I guess we should embrace that? We can upgrade a minor of Hibernate
Search to use Hibernate ORM 5 when it comes, that will fix the
alignment of planets.
Still, we also had hopes for a quick version 6 ..
Just some thoughts.
Thanks,
Sanne
11 years
[OGM] JIRA components for backends
by Gunnar Morling
Hi,
As we had discussed a while ago, I have created a dedicated JIRA component
for each of our backends in OGM.
This means we don't have to encode the backend in issue titles anymore.
Thanks to Hardy's release script, the component name will be added to issue
titles in the change logs. Just make sure issues you are working on are
assigned to the right component.
The previous "datastore" component should not be used any longer for issues
we work on from now on. Unfortunately there is no component archiving
feature in JIRA, so we cannot actually disable the legacy component. I have
renamed it so it shows up last in the drop-down. It's not perfect, but the
alternative would be to physically delete it, which I dislike as it'd
affect all the closed issues linked to it.
Cheers,
--Gunnar
11 years
disabling envers during runtime
by Brett Meyer
In older ORM versions, Envers could be dynamically disabled during runtime by creating an AuditEventListener delegate and surrounding the super calls with custom logic. Info: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...
Now that the architecture is different (EnversListener), any thoughts on alternatives? Having trouble finding ideas...
In addition, is there a way to disable envers during SF bootstrapping? Ie, set some sort of "hibernate.envers.disable" property?
11 years
Re: [hibernate-dev] [wildfly-dev] WildFly 9.0.0.CR1 is released!
by Steve Ebersole
FWIW, those hooks in Hibernate 5 already exist, based on Jandex 1, of
course :)
We are not currently using Jandex. That was work happening under the
metamodel redesign, which we had to push to 6.0.
When we do start using Jandex, the plan is to use the provided Jandex as a
base. But the problem always has been that Hibernate needs to augment that
information from orm.xml. Also we do have to manage cases outside of
WildFly, so we'd have to build the Index manually. Also, I want to look at
the building of an index as a build-time step, storing some representation
of that index into the artifact. We can then locate that representation at
runtime and load it via resource lookup, depending on what that saves/gains
us perf wise (tbd). Again this along with the passed Jandex index serve as
the base index. We at least still need to do that augmentation as Jandex
does not handle that at all.
What is "end of deployment"? Is that the end of phase-2 in our 2-phase JPA
bootstrap design? If so, that should be fine.
On Tue, May 5, 2015 at 10:54 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
> Best to talk with Jason but I heard that the Jandex indexes will soon be
> larger (as part of the Java 8 changes). As a result of the size
> changes, Jandex indexes should only be accessed during the WildFly
> deployment phases.
>
> I'm not sure how Hibernate would use Jandex2 without creating its own
> instances of the indexes, which would be expensive memory wise.
>
> There is also the Hibernate 5.0 release, that we want to integrate with
> WildFly. I think that is where we might tightly couple Hibernate ORM
> with Jandex, by passing a composite index into Hibernate. The Jandex
> reference will need to be cleared by the end of deployment. Would that
> help?
>
> On 05/04/2015 01:53 PM, Sanne Grinovero wrote:
> > Is it possible for our other projects (like Hibernate) to start using
> > Jandex2 sooner rather than later, w/o banning our users from WildFly
> > 9?
> >
> > We're in an innovation paradox ;-)
> >
> > Thanks,
> > Sanne
> >
> >
> > On 4 May 2015 at 15:07, Jason T. Greene <jason.greene(a)redhat.com> wrote:
> >> Yes that's correct. We need to make some deployer changes to prevent
> holding on to indexes.
> >>
> >> Sent from my iPhone
> >>
> >>> On May 4, 2015, at 6:25 AM, Jozef Hartinger <jharting(a)redhat.com>
> wrote:
> >>>
> >>> Congrats on the release!
> >>>
> >>> It seems that Jandex upgrade to 2.0 has not been done yet. Is my
> understanding correct that it has been postponed till WF10?
> >>>
> >>>> On 05/01/2015 10:38 PM, Jason Greene wrote:
> >>>> Hello Everyone,
> >>>>
> >>>> I am happy to announce the first candidate release of WildFly 9!
> WildFly 9 builds off of WildFly 8’s Java EE7 support, and adds many new
> capabilities, including intelligent load balancing, HTTP/2 support, a new
> offline CLI mode, graceful single node shutdown, and a new Servlet-only
> distribution.
> >>>>
> >>>> For more details, check out the release notes:
> >>>> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes
> >>>>
> >>>> As always, you can download it here:
> >>>> http://wildfly.org/downloads/
> >>>>
> >>>> --
> >>>> Jason T. Greene
> >>>> WildFly Lead / JBoss EAP Platform Architect
> >>>> JBoss, a division of Red Hat
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
11 years
Which versions of the application server should the Hibernate OGM modules support
by Sanne Grinovero
Hello all,
I actually have multiple questions on the subject.
# Module name
The Maven artifact id of the modules we're producing for WildFly 8 is
aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
I still think that's a good choice, as deploying modules is an
operation which is strictly coupled to the application server version.
I'm merly reminding this point as it suggests we *could* if - we want
to - easily produce modules for multiple application server versions.
# EAP versions
We're also producing modules for JBoss EAP6, but AFAIR these need some
love and I'm not sure if it's worth the effort - it might not need to
much work and I'm happy to look at it if you want to, but in case we
fix it these should have proper integration tests [next]:
# Integration tests of these modules
The current solution is that the integration tests are run with a
profile selection: so we choose upfront in the build if we want to
test the wildfly8 modules or the eap6 modules.
Are we still happy with this setup? I don't see a CI job which
verifies the EAP6 modules and I doubt you're all running the tests
twice.
Should we:
A) add the CI job to verify the other profiles (EAP6 and others as needed)
B) change approach and have the tests re-run for any build
C) remove the EAP6 modules
My vote goes for B, even though it will make test runs take a bit
longer. To improve speed we can do other things - to be discussed
separately so I'd hope we don't give the execution speed too much
weight for the above choice.
# WildFly 8 vs WildFly 9
At the last meeting we agreed to support WildFly 9. We didn't decide
at what cost towards WF8 users: should we drop the WF8 modules?
I think I'm ok with dropping the older modules, however since we have
chosen for a module name which includes the version, it's pretty easy
for us to keep the WF8 modules around for now, and it's equally easy
to remove them from the project in future when we don't want to do
that anymore.
Documentation (user complexity) wise the instructions would be
identical so it's not a big burden to explain - one would just need to
pick the right set of modules.
I would prefer to keep the WF8 modules around for a little bit, but
only if we agree on an integration testing strategy which is able to
cover all the modules we build.
# JBoss Logger version
As a reminder, there's an update for JBoss Logger which - if applied -
will make it harder for OGM to work on WF8. Gunnar is making some
interesting suggestions to work around this on OGM-803 but let's see
first if
- we really want to keep WF8
- cant we not simply wait to update, I don't see why we should seel
trouble by upgrading this component now.
Sanne
11 years
