Re: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
by Steve Ebersole
On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic(a)gmail.com>
wrote:
> I am confused how you are "mind mapping" PreparedStatement parameters and
>> entity construction into the same conversation. We are not instantiating
>> entities based on PreparedStatement parameters....
>>
>
> I'm not sure I understand you, I haven't mentioned PreparedStatement
> parameters anywhere.
>
Well you mentioned Java 8 parameters names in the subject. I have no idea
what "Java 8 parameter names" might mean outside of the support added in
Java 8 for named parameter binding. So if that's not what you mean, what
do you mean?
Based on some of your other replies, perhaps you are confusing "parameter
names" (PreparedStatement) and "column names" (ResultSet)?
What you propose is to delay the entity instantiation and create the entity
>> instance from after we have the hydrated state.
>
>
> Yes, the requirement for this to work is that before calling constructor
> you have all arguments and target parameter names available.
>
Right, which precludes lazy loading; which is my point on the Jira.
5 years
What's the identity of Hibernate OGM's "public API" module?
by Sanne Grinovero
I'm reviewing how we expect people to use the Hibernate OGM modules on WildFly.
Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.
See also :
- https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:
org.hibernate.ogm services, org.hibernate.ogm.couchdb services
See the difference? We expect people to explicitly import he couchdb module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.
I'd like to get rid of the need specify modules. I see several paths,
some less compelling:
A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
pros: it's done :)
cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?
B- have WildFly inject all these modules on the user's classpath
pros: consistency, no magic, everyone gets the same.
cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?
C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
pros: exposes the minimum but not less
cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.
C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
pros: we can control and evolve this as we realise which mistakes
we're making :)
cons: more complex to define this contract?
My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.
Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a specific version,
or at least allow overrides like we do with Search.
Thanks,
Sanne
5 years
http://www.hibernatespatial.org/
by Steve Ebersole
Karel, a user was asking about problems using the hibernate-spatial mailing
list on IRC which precipitated a discussion about how we want deal with
these things moving forward. For example, the
http://www.hibernatespatial.org/ site is still up and running and really
has no indication that the move to integrate Spatial into Hibernate proper
was completed. What do you want to have happen with that website/URL?
As for other infrastructure, what would you like to have happen? It seems
like hibernate-spatial is a more user-focused mailing list, as opposed to a
dev mailing list? If so, Hibernate does not really do user mailing lists.
We prefer the forums or StackOverflow for user questions, so there is not a
straight "migration". You can obviously keep the hibernate-spatial mailing
list running too, but we should have some idea how to help users who are
having trouble with it on the website (which website depends on what you
decide to do with http://www.hibernatespatial.org/.
Any other things we should discuss in terms of infrastructure?
Davide, what was the exact problem the user on IRC was complaining about
wrt the hibernate-spatial mailing list?
5 years
6.0 planning
by Steve Ebersole
We have been having a few side discussions about plans for 6.0, and I
thought it would be a good idea to consolidate them together.
1. Incorporate the SQM work. Lots of pieces go into this:
1. Replacing the interpretation of HQL/JPQL and Criteria queries.
2. *Possibly* leveraging SQM to deal with entity operations
(load-by-id, merge, etc).
3. Improved Query contracts
4. Improved persister contracts (including addition of an "embeddable
persister").
5. Improved Type contracts
2. Extensions to JPA criteria based on SQM work(this is probably more on
ongoing 6.x task)
3. Baseline on Java 8
Is there anything else anyone wants to discuss getting included?
Another one I'd like to discuss is the consolidation of the hibernate-core
and hibernate-entitymanager modules into a single module (possibly renamed
hibernate-orm). There are a lot of reasons and benefits to doing this:
1. A major one would be the consolidation of "type systems". Hibernate
has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now with
SQM we have a 3rd type system in play.
2. It is also the major hurdle to moving to being able to fully replace
the legacy criteria with JPA criteria. If Session and EntityManager (as
well as SessionFactory ad EntiytManagerFactory) were fully integrated then
Session would be able to build/handle JPA criteria queries.
3. Simplified HEM bootstrapping
There are also a few challenges to doing this consolidation of the
hibernate-core and hibernate-entitymanager modules. The big one tht stick
out in my head is event-listener with different behaviors between core and
hem.
5 years, 1 month
[OGM] Reduce the integrationtest directiry size
by Emmanuel Bernard
I noticed that for each integration test module we do download a full Wildfly distribution. Since we are having more and more integration test module it adds up significantly. On top of that the integrationtest module itself also downloads Wildfly. The current size is of integrationtest is 1.3 GB with most of it attributed to Wildfly. Could we share the same download somehow ?
On a side note, what are the ORM target/test-results/binary/test/output.bin? In my quest for more space I stumbled upon them.
Emmanuel
5 years, 1 month
