[OGM] storing the column names in the entity keys for K/V stores
by Emmanuel Bernard
Hi,
With OGM-452 behind us which brings one cache per “table”, we now have
another decision in front of us.
Should we use a synthetic key for the cache key (say a
PersistentEntityKey class containing the array of column names and the
array of column values)?
Or should we use the natural object key?
== Natural entity key
In the latter, things gets complicated quickly, let me explain:
=== Simple case
For simple cases, the id is a simple property and the fit is very
natural
[source]
--
@Entity
class User {
@Id String name;
...
}
//corresponds to
cache.put(name, mapRepresentingUser);
--
=== Embedded id
If the identifier is an embedded id, you have several choices that all have
drawbacks.
1. use the embedded id class as key `cache.put( new Name("Emmanuel", "Bernard"), mapRepresentingUser );`
2. use an array of property values `cache.put( new Object[] {"Emmanuel", "Bernard"}, mapRepresentingUser );`
3. use a Map<String,Object> corresponding to the array `cache.put( new HashMap<String,Object>( {{ "firstname" -> "Emmanuel", "lastname"->"Bernard" } ), mapRepresentingUser );
4. use an synthetic key `cache.put( new PersistentEntityKey( new String[] {"firstname", "lastname" }, new String[] { "Emmanuel", "Bernard" } ), mapRepresentingUser);`
In 1, the problem is that we lose the proper data type abstraction
between the object model and the data stored. `Name` is a user class.
In 2, I think the model is somewhat acceptable but a bit arbitrary.
In 3, I suspect the map is pretty horrific to serialize - that could be
solved by a externalizer. But more importantly the order of the id
columns is lost - even though it might be recoverable with
EntityKeyMetadata?
In 4, we expose the person querying the grid to our OGM specific type.
Aside from this, it is essentially like 4.
=== Entity key approach
I really like the idea of the simple case be mapped directly, it makes
for *the* natural mapping one would have chosen. But as I explained, it
does not scale.
In the composite id case, I don't really know what to chose between 2, 3
and 4.
So, should we go for the simple case if we can? Or favor consistency
between the simple and complex case?
And which of the complex case do we favor?
== Association
In the case of associations, it becomes a bit trickier because the
"simple case" where the association key is made of a single column is
quite uncommon. Association keys are one of these combinations:
* the fk to the owning entity + the index or key of the List or Map
* the fk to the owning entity + the fk to the target entity (Set)
* the fk to the owning entity + the list of columns of the simple or
* embedded type (Set)
* the fk to the owning entity + the surrogate id of the Bag
* all columns in case of a non id backed bag
All that to say that we are most of the time in the complex case of
EntityKey with one of the 4 choices.
Any thoughts and preferences?
Emmanuel
11 years
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.
11 years, 1 month
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
11 years, 1 month
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
> >
>
11 years, 1 month
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.
11 years, 1 month
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
11 years, 1 month
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.
11 years, 1 month
