ORM master
by Steve Ebersole
Per the face to face discussion yesterday (I'll send out more details
later) I am working on branching master off to a new "metamodel" dev branch
and priming a "new master" from 4.3 (the basic idea being to start work on
a more targeted 5.0).
Part of this is of course a massive change to the state of master upstream.
If anyone needs me to wait before starting this please let me know
immediately. Thanks.
9 years, 5 months
MySQL fractional second precision (HHH-9444)
by Gail Badner
MySQL support for fractional seconds in temporal values is documented in [1]:
Prior to MySQL 5.6.4, when storing a value into a column of any temporal data type, fractional part is discarded (truncated). When a column is defined as TIMESTAMP(N), N indicates display width rather than fractional seconds.
MySQL 5.6.4 and up allows enabling fractional second support by defining a column like: TIME(n), DATETIME(n), TIMESTAMP(n), where 0 <= n <= 6. A value of 0 indicates no fractional seconds. For compatibiliby with previous MySQL versions, if no value for n is provided, then 0 is the default. This is inconsistent with standard SQL, which has a default of 6. In addition, inserting a temporal value in a column will result in rounding if the column is defined with fewer fractional digits than the value.
Starting from MySQL 5.6.4, there are also differences in functions that involve temporal values. MySQL functions like NOW(), CURTIME(), SYSDATE(), or UTC_TIMESTAMP() can optionally take an argument for fractional seconds precision as in NOW(n), CURTIME(n), SYSDATE(n), or UTC_TIMESTAMP(n), where 0 <= n <= 6. For compatibiliby with previous MySQL versions, if no value for n is provided, then 0 is the default.
I'm working on a new dialect to support fractional seconds. Since the support for fractional seconds began in MySQL 5.6.4 it kind of complicates naming. I assume MySQL5InnoDBDialect needs to be extended for the InnoDB engine.
Is "MySQL564InnoDBDialect" too ugly?
Is there any need to have a new dialect for other (non-InnoDB) MySQL engines (e.g., MySQL564DBDialect that extends MySQL5Dialect)?
IIUC, to be consistent with the SQL standard the default for the temporal types in the new dialect(s) should be:
registerColumnType( Types.TIMESTAMP, "datetime(6)" );
registerColumnType( Types.TIME, "time(6)" );
Is there a need the new dialect(s) to allow an application to define the number of fractional seconds to anything other than 6? If so, would it work to also add the following?
registerColumnType( Types.TIMESTAMP, 6, "datetime($l)" );
registerColumnType( Types.TIME, 6, "time($l)" );
Also, IMO, Hibernate should render NOW(), CURTIME(), SYSDATE(), UTC_TIMESTAMP() as NOW(6), CURTIME(6), SYSDATE(6), or UTC_TIMESTAMP(6), respectively, unless an argument is specifically provided.
As far as I can tell, Hibernate does not use MySQL's TIMESTAMP column type, so I don't think anything needs to be done to support fractional seconds for that type, or am I missing something here?
Comments?
Thanks,
Gail
[1] http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html
[2] https://hibernate.atlassian.net/browse/HHH-9444
9 years, 5 months
Re: [hibernate-dev] Hibernate ORM master - 5.0
by Gail Badner
Forgot to CC hibernate-dev mailing list...
----- Original Message -----
> From: "Gail Badner" <gbadner(a)redhat.com>
> To: "Steve Ebersole" <steve(a)hibernate.org>
> Sent: Tuesday, November 18, 2014 9:28:02 AM
> Subject: Re: [hibernate-dev] Hibernate ORM master - 5.0
>
> You mention possibly for 5.1: "Override EAGER fetching with LAZY (fetch
> profiles, HQL, etc) refer to HHH-8558 and HHH-8559?
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve(a)hibernate.org>
> > To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org>
> > Sent: Thursday, October 30, 2014 8:44:23 AM
> > Subject: [hibernate-dev] Hibernate ORM master - 5.0
> >
> > It was decided that the massive work for 5.0 including metamodel and all
> > the other changes was just taking too long, and that we'd split that work
> > up into a number of intermediate versions. I wanted to highlight the
> > proposed breakdown and solidify the roadmaps. The preliminary breakdown is
> > as follows:
> >
> >
> > - 5.0
> > - Java 6 or 7 (?)
> > - EE 7 (JPA 2.1)
> > - Wildfly 9
> > - Timeline : Spring 2015
> > - Required development
> > - Transition to new bootstrapping APIs
> > - MetadataSources, contributors, builders, etc for building
> > SessionFactory
> > - Keep Configuration as a migration aid, but align its
> > processing and assumptions to follow new APIs
> > - New naming strategy approach (implicit and physical split)
> > - Pick "important" features from metamodel work based on new
> > bootstrapping API
> > - automatic quoting of identifiers that are keywords
> > - ???
> > - Performance improvements
> > - Cachng SPI changes based on feedback from Ehcahce and Infinispan
> > - EntityKey proposal
> > - Explore unifying entry keys for actual cache provider, cache
> > SPI (CacheKey) and persistence-context (EntityKey)
> > - Infinispan improvements, especially in local mode. Will
> > require integrating a new Infinispan version and possible
> > changes to
> > hibernate-infinispan
> > - ???
> > - OGM integration
> > - "after persisters built" hook
> > - others?
> > - Java 8 type support
> > - Date/Time
> > - Optional
> > - Java 9 type support
> > - Money/Currency
> > - Optional development (as time, resources allow)
> > - Discriminator based multitenancy
> > - JAXB instead of dom4j.
> > - extended orm.xml xsd, deprecating hbm.xml format
> > - Jandex usage
> > - JdbcSession
> > - Hibernate Spatial integration (depends on level of dependence on
> > metamodel)
> > - 5.1
> > - Java 6 or 7 (?)
> > - EE 7 (JPA 2.1)
> > - Widfly 9, or 10
> > - Timeline : TBD (Fall 2016?)
> > - Required development
> > - slips from 5.0
> > - new HQL parser
> > - Antlr 3 or 4?
> > - unified SQL generation? or limit to HQL parsing?
> > - Optional development (as time, resources allow)
> > - extend JPA criteria API with support for constructs from
> > Hibernate's legacy criteria API
> > - extend JPA criteria API with fluent support
> > - Possibly - Override EAGER fetching with LAZY (fetch profiles, HQL,
> > etc)
> > - 5.2
> > - (if needed)
> > - Java 6 or 7 (?)
> > - EE 7 (JPA 2.1)
> > - Widfly 9, or 10
> > - Required development
> > - splits from 5.1
> > - 6.0
> > - SE and EE support levels TBD, but at least SE 8
> > - Required development
> > - metamodel
> >
> >
> > One additional consideration... I have been told (have not verified the
> > details yet myself) that Hibernate ORM will currently not run in Java 8 at
> > least in part because dom4j will not work in Java 8 (maybe just the version
> > we use? again, have not verified details yet). If running 5.x versions of
> > Hibernate in Java 8 is important to anyone, we might need to increase the
> > priority of moving to JAXB over dom4j.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
9 years, 5 months
Re: [hibernate-dev] ORM build - IDE imports
by Steve Ebersole
>
>
> Personally, I am not a big fan of changing build structure for the purpose
> of an
> IDE. generated-src belong imo into target.
>
> That said, I know the troubles of having to manually adjust the Idea
> configuration
> after importing. If it bothers you so much or if you had several reports
> of people
> having problems setting up the project in the IDE, I's say go for it.
>
Yes, this is completely a pragmatic consideration. I set the build up with
generated-src under target because that is what I believe is proper in the
idyllic sense. But at some point I'd like to have an import that
JustWorks(tm).
> > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as
> the
> > best-case scenario.
>
> Not sure what you mean? Are you referring to the actual annotation
> processor module
> or do you mean that you want to statically check in the generated meta
> model classes
> needed for our tests in the hibernate-core/hibernate-entitymanager module?
> I assume
> the latter. Again, not a big fan.
>
No, I actually mean the former. Probably as an alternative to the AP-based
generation, I think a non-AP solution would be good. After having talked
to David a few times about this, I believe annotation processing is not the
proper way to be generating these classes. My new belief is that
annotation processors that generate code that is then needed to compile is
bad mojo.
>
> > It seems to me the only real option currently is to expect a full compile
> > prior to import.
>
> Right. Something I would recommend anyways.
>
Dunno here. Often my initial touch point with a project is to check out
the code and import it into the IDE. And I think that I am not unusual in
that sense, so I think there is a ton of value in that working smoothly.
> Speaking of the hibernate-testing circularity, I do still want to get rid
> > of that. Currently I have been waiting on Gradle adding support for
> > publishing multiple artifacts from a project (module).
>
> That would be nice. Is there an issue for that? Did they agree on
> implementing
> it?
>
They said it was something they wanted to do. I'll follow up to see if it
was ever done.
9 years, 5 months
Allowing auto-close usage for Session
by Sanne Grinovero
I was expecting this to be a trivial and non-API breaking change, but
it turns out the close() method for Session doesn't return void, and
so is not compatible with the Closeable inteface:
/**
* End the session by releasing the JDBC connection and cleaning up. It is
* not strictly necessary to close the session but you must at least
* {@link #disconnect()} it.
*
* @return the connection provided by the application or null.
* @throws HibernateException Indicates problems cleaning up.
*/
public Connection close() throws HibernateException;
So this change can't be applied in 4.3 yet, but I'd hope to finally
send a PR for 5.0 at least;
Assuming that some applications really need that Connection instance,
my proposal would be to split the functionality across two methods:
public Connection closeAndReturnConnection();
public void close();
Any better names / ideas?
Second question: we had previously decided to implement
java.io.Closeable, so that it would work also for users of Java6. But
if for the above reason, this is getting into master only, then I
guess we could reopen that subject: would you prefer to have it extend
just java.lang.AutoCloseable ?
Sanne
9 years, 5 months
Hibernate ORM master - 5.0
by Steve Ebersole
It was decided that the massive work for 5.0 including metamodel and all
the other changes was just taking too long, and that we'd split that work
up into a number of intermediate versions. I wanted to highlight the
proposed breakdown and solidify the roadmaps. The preliminary breakdown is
as follows:
- 5.0
- Java 6 or 7 (?)
- EE 7 (JPA 2.1)
- Wildfly 9
- Timeline : Spring 2015
- Required development
- Transition to new bootstrapping APIs
- MetadataSources, contributors, builders, etc for building
SessionFactory
- Keep Configuration as a migration aid, but align its
processing and assumptions to follow new APIs
- New naming strategy approach (implicit and physical split)
- Pick "important" features from metamodel work based on new
bootstrapping API
- automatic quoting of identifiers that are keywords
- ???
- Performance improvements
- Cachng SPI changes based on feedback from Ehcahce and Infinispan
- EntityKey proposal
- Explore unifying entry keys for actual cache provider, cache
SPI (CacheKey) and persistence-context (EntityKey)
- Infinispan improvements, especially in local mode. Will
require integrating a new Infinispan version and possible
changes to
hibernate-infinispan
- ???
- OGM integration
- "after persisters built" hook
- others?
- Java 8 type support
- Date/Time
- Optional
- Java 9 type support
- Money/Currency
- Optional development (as time, resources allow)
- Discriminator based multitenancy
- JAXB instead of dom4j.
- extended orm.xml xsd, deprecating hbm.xml format
- Jandex usage
- JdbcSession
- Hibernate Spatial integration (depends on level of dependence on
metamodel)
- 5.1
- Java 6 or 7 (?)
- EE 7 (JPA 2.1)
- Widfly 9, or 10
- Timeline : TBD (Fall 2016?)
- Required development
- slips from 5.0
- new HQL parser
- Antlr 3 or 4?
- unified SQL generation? or limit to HQL parsing?
- Optional development (as time, resources allow)
- extend JPA criteria API with support for constructs from
Hibernate's legacy criteria API
- extend JPA criteria API with fluent support
- Possibly - Override EAGER fetching with LAZY (fetch profiles, HQL,
etc)
- 5.2
- (if needed)
- Java 6 or 7 (?)
- EE 7 (JPA 2.1)
- Widfly 9, or 10
- Required development
- splits from 5.1
- 6.0
- SE and EE support levels TBD, but at least SE 8
- Required development
- metamodel
One additional consideration... I have been told (have not verified the
details yet myself) that Hibernate ORM will currently not run in Java 8 at
least in part because dom4j will not work in Java 8 (maybe just the version
we use? again, have not verified details yet). If running 5.x versions of
Hibernate in Java 8 is important to anyone, we might need to increase the
priority of moving to JAXB over dom4j.
9 years, 5 months
Exception handling in hibernate
by Sujit.Dhaygude＠sungard.com
Hi ,
we have a requirement to point a record for which the actual batch flush/commit has failed.
Is there a generic way by which hibernate can be hooked up for exception scenario to pull back the actual entity for which
DB/Hibernate Error has occurred .
Most of the times we could see the hibernate is printing the error in logs which has entity ID but which is not consistent.
Currently we are planning to use the Pre and Post (insert/Update/Delete) event handlers to retain the entities in Thread local
and display those in case of error, but these listeners will intercept all the DB operation irrespective of success/failure .
I am looking for a solution which will not impact the overall application performance and only in case of exception we need the details of entity.
Regards,
Sujit
9 years, 5 months
