ORM 5 - Default schema
by Guillaume Smet
Hi,
Still trying to get one of our applications starting with ORM 5. With
Search 5.4.0.Beta1 and Spring 4.2.0.RC1, I'm now at the database schema
validation phase.
I think there's something fishy with the way a table is looked for when
we're using specific schemas in our database.
Some background: we use PostgreSQL, we remove the public schema and we
create a schema which is the default schema for the user.
Our Hibernate app doesn't know anything about the schema and it used to
work fine with ORM 3 and 4.
We like this configuration as the schema used is totally transparent for
the application and we can play with it at the database level without
changing the Hibernate configuration.
The fact is that it doesn't work anymore with ORM 5. The problem is that,
when the schema is null, ORM now considers that the schema should be ""
(empty string) if we haven't set a default schema at the JDBC level. This
leads to trying to find the tables in the "" schema which obviously fails.
AFAICS, it's something specifically wanted as in
NormalizingIdentifierHelperImpl.toMetaDataSchemaName, we have the following
lines:
if ( identifier == null ) {
if ( jdbcEnvironment.getCurrentSchema() == null ) {
return "";
}
identifier = jdbcEnvironment.getCurrentSchema();
}
IMHO, in the null case, if the current schema isn't specified, we should
return null and let the database determine which schema to use instead of
deciding that the schema is "".
If it's null, the schema filter will not be considered and the schema
resolution will be let to the database.
Any thoughts?
--
Guillaume
10 years, 12 months
(HHH-9857) Reuse of EntityEntry for bytecode enhanced read-only reference cached entities
by John O'Hara
Steve,
I missed you ping yesterday about HHH-9857. I reworked based on the
EntityEntry needing to be threadsafe to be shared across sessions. With
the current impl a new EntityEntry is created for each
PeristenceContext. If we share it between sessions, there is a race
condition on the compressedState field, as multiple threads will access
the same object.
We had discussed about making access to this field threadsafe, or
removing some of the operations and making the ImmutableEntityEntry
objects immutable themselves.
I have used a ReadWriteRentrantLock in ImmutableEntityEntry to remove
the race cond. as this appeared to require least code change, but I am
uncertain atm what impact this will have on performance as it is in a
critical section of code. I have not been able to test my changes as we
currently have an issue with our perf lab after a recent upgrade. I will
test as soon as I can to see what impact this has on cpu. This change
only impacts ImmutableEntityEntry, and not MutableEntityEntry
Thanks
John
--
John O'Hara
johara(a)redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
10 years, 12 months
Blog / CI setup
by Sanne Grinovero
Hi all,
the ci server was reconfigured to host our next.gen blog platform;
I have now created a build job here:
http://ci.hibernate.org/view/Website/job/staging.in.relation.to
It's using the following build script:
rake clean
rake setup
rake test gen[staging] && rsync -avh _site/
ci.hibernate.org:/var/www/staging-in.relation.to
Which gets me this error:
http://ci.hibernate.org/view/Website/job/staging.in.relation.to/3/console
I copied this script from the job which builds www.hibernate.org, but
I guess the incantation needs to be different in this case?
I'm not using RVM, I was hoping we could get it work work without it.
Should I just assume RVM is requirement?
I did install the following RPMs:
- gcc
- make
- ruby-devel
- gcc-c++
- libxml2
- libxml2-devel
- libxslt
- libxslt-devel
- rubygem-nokogiri
And these gems:
- rake
- bundler
(both, system wide)
The system-wide ruby version is:
ruby 2.1.6p336 (2015-04-13 revision 50298) [x86_64-linux]
Thanks,
Sanne
11 years
Re: [hibernate-dev] JPA pessimisticLockScope.EXTENDED
by Steve Ebersole
See my comment on the Jira. We can discuss this on IRC if you wish.
On Tue, Jun 9, 2015 at 6:51 AM andrea boriero <andrea(a)hibernate.org> wrote:
> Hi Steve,
>
> I'm getting crazy with https://hibernate.atlassian.net/browse/HHH-9636
> JPA pessimisticLockScope.EXTENDED
>
> 1. EntityManage#lock
> 1. LockMode.PESSIMISTIC_WRITE without extended lock scope adds a
> "for update" just to the parent entity.
> 2. Setting the lock scope to Extended the lock is cascaded only if
> the lock entity is detached because in
> DefaultLockEventListener.onLock(LockEvent event) the cascadeOnLock(event,
> persister, entity) is applyed only if EntityEntry entry =
> source.getPersistenceContext().getEntry(entity) is null ,but anyway is not
> applyed to Components like for the @ElementCollection in the issue
> example. Not sure if this is the intended behavior.
> 2. Entitymanager#createQuery() and EntityManager#find()
> with LockMode.PESSIMISTIC_WRITE and scope Extended add the "for update"
> just to the parent entity.
>
> Can you give me some help with this issue? Also a little explanation about
> the intended behaviour of the PESSIMISTIC_WRITE and the scope is really
> appreciated. The documentation is not so clear and i really want to
> understand it.
>
> Thanks
>
> Andrea
>
>
>
11 years
HHH-9857 - Reuse of EntityEntry for bytecode enhanced read-only reference cached entities
by John O'Hara
For our use case, bytecode enhanced reference cached immutable entities,
our top object for memory allocation is EntityEntry.
We see an EntityEntry object created every time an immutable entity is
added to a persistence context.
In our use case, where we know the entity is immutable and we already
have an EntityEntry cached, can we re-use the EntityEntry between
sessions? This would reduce the allocation rate of EntityEntry in our
use case by ~50%.
--
John O'Hara
johara(a)redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
11 years
Hibernate ORM - next steps
by Steve Ebersole
Now that 5.0 is settling down I wanted to start planning where we go from
here in terms of feature development and schedule/releases.
Here is my high-level list of features/work:
* rework SQL generation & HQL parser
* change JDBC extraction to work by position, rather than alias (reworking
SQL generation is a prerequisite)
* rework annotation binding (Jandex, etc)
* extended orm.xml, deprecate hbm.xml
* discriminator-based multi-tenancy
* port Hibernate Criteria constructs to JPA criteria, begin deprecation of
Hibernate Criteria
* extend JPA criteria API with fluent support
* ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
* merging hibernate-entitymanager into hibernate-core
* continue to fill out bytecode enhancement capabilities
Some of these are more involved than others. The task for re-writing SQL
generation is a HUGE undertaking, but also has many huge benefits.
Re-writing annotation binding is another huge undertaking, but again with
many benefits.
Any others we should add to the list here?
And then we can work on scheduling them.
11 years
HHH-9789: collection size() with lazy extra does not applies filters if proxy is not initialized
by Hernán Chanfreau
Hi!
A time ago I created this issue. The problem is this:
When using lazy extra and enabling filters affecting the collection, the
size() and isEmpty() methods are not applying the filters when the
collection proxy isn't initialized.
So, enabling filters and accessing a collection marked as lazy extra (the
filters applying to it), the methods size() and isEmpty() returns
differents values:
- if the proxy is initialized, the methods access the real filtered
collection.
- if the proxy is not initialized, the methods fire a separated select
count(*) ignoring the filters.
I´ve attached a test case.
I'm wondering if this scenario breaks the idea of not fetching the
collection if is not really needed (for lazy extra collections) or, we can
add on the fly the filters conditions to the select count(*) in order to
avoid fetching it.
What do you think?
Regards. Hernán.
11 years
