HHH-10162 Inheritance and L2 cache
by Christian Beikov
Hey guys,
Steve said I should start a discussion about the possible solution for
HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we go.
While debugging the issue, I found out that the proxy is created at
DefaultLoadEventListener.createProxyIfNecessary() where it IMO should
consult the 2L cache first by calling existing =
loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks
easy, but I am not sure of the implications. Obviously this will affect
performance a little since it has to consult the L2 cache now.
I tried to start a discussion in the Dev room, but so far only Andrea,
Vlad and Chris have commented this. Has anyone a different idea for
implementing this?
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
7 years
6.0 proposal - CollectionTuplizer
by Steve Ebersole
As part of removing most Type sub-types we are left with the question of
how to handle the role served by CollectionType. Andrea and I came up with
a proposal that not only serves that purpose but also allows a level of
customization we have so far not supported but which has been asked for a
few times (mostly as part of framework/language integration into Hibernate;
Ceylon, etc).
Here is the proposal:
/**
* Encapsulates collection type specific behavior/information
* <p/>
* NOTE : the name "tuplizer" was chosen as this really serves
* same logical purpose as the entity and component tuplizers
* do entities and components respectively.
*/
interface CollectionTuplizer<C> {
/**
* Access to the type of the collection. This
* is expected to be an interface. Used to create
* a registry against which we can resolve the
* reflected attribute type. E.g. an attribute
* defined as `List` would be resolved to the
* CollectionTuplizer that deals with lists
*/
Class<C> getCollectionJavaType();
/**
* Create an empty instance of the collection wrapper
*/
PersistentCollection<C> create(int anticipatedSize);
/**
* Wrap an existing "raw" view of the collection
*/
PersistentCollection<C> wrap(Object rawCollection);
/**
* Creates the representation of this plural attribute
* according to the runtime domain model view.
*/
<O> PluralPersistentAttribute<O,C,?> generatePluralAttribute();
// anytihng else? element comparator, etc?
}
Thoughts? Suggestions?
7 years, 6 months
SQM and cast targets
by Steve Ebersole
Currently casting in HQL is under-defined and open-ended (and therefore
pretty inconsistent). What does that mean? Well, what is a valid cast
target in HQL? There really is not a defined
answer to that.
I'd like to start formalizing the answer to this.
Specifically, I am thinking this should be defined around
JavaTypeDescriptor. So that we'd understand any Java type registered with
with JavaTypeDescriptorRegistry, and specifically any that properly
implements `#getJdbcRecommendedSqlType` (using the Dialect to resolve the
cast target in the generated SQL).
Anyone have objections to this? Thoughts?
7 years, 6 months
6.0 - formalized standard functions
by Steve Ebersole
Hibernate has always defined a set of functions that should always be
available on every Dialect/database. JPA formalized some of these, but
Hibernate still had a superset. So I wanted to formalize the complete set
of supported functions. Here is the formalized list of what Hibernate has
always considered the "supported list":
- those defined by JPA
- abs
- avg
- concat
- count
- current_date
- current_time
- current_timestamp
- length
- locate
- lower
- max
- min
- mod
- sqrt
- substring
- sum
- trim
- upper
- Hibernate extensions
- bit_length
- coalesce - not technically a function, but supported as such to
allow overriding
- cast
- day - generally defined as `extract(day from ?1)`
- extract
- hour - generally defined as `extract(hour from ?1)`
- minute - generally defined as `extract(minute from ?1)`
- month - generally defined as `extract(month from ?1)`
- nullif - not technically a function, but supported as such to allow
overriding
- second - generally defined as `extract(second from ?1)`
- str - generally defined as `cast(?1 as CHAR )`
- year - generally defined as `extract(year from ?1)`
Additions/subtractions anyone would like to discuss?
One question I has was in regards to str being defined as `cast(?1 as CHAR
)` by default - specifically using CHAR instead of VARCHAR. Some databases
apply padding for the size of the datatype when casting a numeric to a CHAR
which is not an unreasonable thing to do.
7 years, 6 months
Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell
Hi Sanne,
I would second Dalibor's request to share your feedback!
Thanks,Rory
On 19/05/2017 13:06, dalibor topic wrote:
> On 19.05.2017 13:49, Sanne Grinovero wrote:
>> Hi Rory,
>>
>> thanks, I'll update our ci.hibernate.org build servers today.
>>
>> Status reminder: we had good progress some months back, but since
>> Gradle broke again we're stuck on our flagship project (Hibernate
>> ORM).
>
> Yeah :/ Aside from the ongoing discussion about getenv improvements
> for gradle on core-libs-dev, I hope that Mark's latest proposal will
> help remove some of the roadblocks in this area.
>
> Speaking of which - if you have a spare moment, I think this kind of
> feedback would be great to have directly on jigsaw-dev. As with many
> other JDK changes, the potential impact upon framework developers can
> best be understood by such developers themselves and should be brought
> back to JDK lists for discussions. In particular when default settings
> end up changing ;)
>
> cheers,
> dalibor topic
>
>> Some progress can be monitored here:
>> - http://ci.hibernate.org/view/JDK9/
>>
>> Please bear in mind that even the "green" projects had to disable
>> integration tests with various platforms: our goal is to fix our own
>> code but that doesn't mean that it's going to work in the thousands of
>> frameworks integrating our projects.
>>
>> Mark Reinhold's latest proposal looks like a great step into the right
>> direction.
>>
>> I can't speak for my colleagues: [I don't represent Red Hat Middleware
>> !] but indeed - as an opinion from the Hibernate team - having some
>> ways to mitigate the high time pressure is very well received.
>> Whatever is decided regarding the default value of that flag, we'll
>> certainly keep testing on the strictest setting, and keep stressing
>> integrating frameworks and containers to do the same.
>>
>> Also as a personal opinion, not having the ability to isolate modules
>> in terms of avoiding conflicting package names is going to make
>> progress much harder: several of the projects we integrate with are
>> extremely conservative in breaking APIs, so renaming packages for the
>> sake of making the modules system happy is not going to happen in a
>> long time. Also future evolution of our projects will likely be
>> affected. In my experience I've witnessed several times that excellent
>> libraries are "transferred ownership" across organisations and
>> maintainers, sometimes partially, and when they get split they are
>> typically not in a suitable time to rename all packages. Sure such
>> things get cleaned up, but such events have to be decoupled - often
>> for organisational, practical reasons.
>>
>> Successful OSS projects grow in size and complexity, but they don't
>> necessarily scale in funding when they rely on volunteers, so an
>> organic growth followed by splits is quite natural. The Java ecosystem
>> supported this nicely; good tooling has been accelerating the process
>> and allowing for larger projects but we're at a saturation point for
>> which we're hoping modules would be an enabler for the community to
>> avoid headaches with dependency alignment puzzles. With no isolation
>> of at least the not-exported classes this seems like a missed
>> opportunity.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 19 May 2017 at 11:37, Rory O'Donnell <rory.odonnell(a)oracle.com>
>> wrote:
>>> Hi Sanne,
>>>
>>> *JDK 9 Early Access* build 170 is available at the new location : -
>>> jdk.java.net/9/
>>>
>>> A summary of all the changes in this build are listed here
>>> <http://download.java.net/java/jdk9/changes/jdk-9+170.html>.
>>>
>>> Changes which were introduced since the last availability email that
>>> may
>>> be of interest :
>>>
>>> * b168 - JDK-8175814: Update default HttpClient protocol version and
>>> optional request version
>>> o related to JEP 110 : HTTP/2 Client.
>>> * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
>>> o changes in command line options
>>> * b170 - JDK-8177153 : LambdaMetafactory has default
>>> constructorIncompatible change,
>>> o release note: JDK-8180035
>>>
>>> *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
>>> mailing list *[1]
>>>
>>> * Proposal: Allow illegal reflective access by default in JDK 9
>>>
>>> In short, the existing "big kill switch" of the
>>> `--permit-illegal-access`
>>> option [1] will become the default behavior of the JDK 9
>>> run-time system,
>>> though without as many warnings. The current behavior of JDK 9,
>>> in which
>>> illegal reflective-access operations from code on the class path
>>> are not
>>> permitted, will become the default in a future release. Nothing
>>> will
>>> change at compile time.
>>>
>>>
>>> Rgds,Rory
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
>>>
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 7 months
JDK 9 EA Build 170 is available on jdk.java.net
by Rory O'Donnell
Hi Sanne,
*JDK 9 Early Access* build 170 is available at the new location : -
jdk.java.net/9/
A summary of all the changes in this build are listed here
<http://download.java.net/java/jdk9/changes/jdk-9+170.html>.
Changes which were introduced since the last availability email that may
be of interest :
* b168 - JDK-8175814: Update default HttpClient protocol version and
optional request version
o related to JEP 110 : HTTP/2 Client.
* b169 - JDK-8178380 : Module system implementation refresh (5/2017)
o changes in command line options
* b170 - JDK-8177153 : LambdaMetafactory has default
constructorIncompatible change,
o release note: JDK-8180035
*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
mailing list *[1]
* Proposal: Allow illegal reflective access by default in JDK 9
In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings. The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release. Nothing will
change at compile time.
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 7 months
