Skip to content

Instantly share code, notes, and snippets.

@sebersole

sebersole/todo.adoc

Last active April 6, 2017 15:52
Show Gist options
  • Save sebersole/78ca7dcdc59c36c45f1cf3ec2e0b54dc to your computer and use it in GitHub Desktop.
Save sebersole/78ca7dcdc59c36c45f1cf3ec2e0b54dc to your computer and use it in GitHub Desktop.
Download ZIP
Raw
todo.adoc

Active questions and todo list for 6.0

A list of work to do (and questions to be answered) with regard to ORM 6.0 and 6.x.

This categorization follows MoSCoW paradigm.

Related major Jira issues

  • HHH-10954 - Integrate SQM into upstream ORM

  • HHH-10873 - Type systems consolidation + org.hibernate.type refactoring

  • HHH-11263 - Introduce BootstrapContext

  • HHH-11356 - Adjust the 2nd-Cache SPIs to better reflect supported uses

  • HHH-11391 - Improved metadata about a basic-typed value

  • HHH-11358 - Changes to persister contracts

  • HHH-11478 - General package restructuring

Must

Things listed as must are things that have to be implemented for 6.0. We break these down into various unstable release categories for scheduling purposes. Some items may be promoted (from Alpha2 to Alpha1 e.g.) or demoted (from Alpha1 to Alpha2 e.g.) as resources dictate.

Once Alpha1 is released, the plan is to enter a timebox schedule for the others - most likely a 6-week timebox schedule.

Alpha1

  • Drop Query#iterate support (shallow queries)?

  • Determine how to deal with org.hibernate.sqm.parser.criteria.tree.JpaExpression#getExpressionSqmType. It is only used in "basic contexts" (function return types, arithmetic results, etc)

  • split concept of NavigablePath and NavigableRole (PropertyPath renamed). NavigablePath represents an ongoing path in a query; NavigableRole represents the static role of an attribute in relation to a root entity

  • keep org.hibernate.loader.plan.spi.LoadPlan, but deprecate it favor of org.hibernate.sql.convert.spi.SqlSelectPlan / org.hibernate.sql.exec.spi.JdbcSelect.

  • find all usage of LoadPlan and replace it with SqmSelectInterpretation, this will include delegation between various load-plan contracts and the SQL-AST counter-part, such as:

    • AssociationVisitationStrategy → NavigableVisitationStrategy

    • EntityDefinition → ? EntityReference or EntityPersister?

    • AttributeSource → ? PersistentAttribute or Navigable?

    • org.hibernate.loader.plan.spi.Return → org.hibernate.sql.convert.results.spi.Return

      • org.hibernate.loader.plan.spi.ScalarReturn → org.hibernate.sql.convert.results.spi.ReturnScalar

      • org.hibernate.loader.plan.spi.EntityReturn → org.hibernate.sql.convert.results.spi.ReturnEntity

      • etc..

    • org.hibernate.loader.plan.spi.QuerySpaces → org.hibernate.sql.ast.from.FromClause ?

      • org.hibernate.loader.plan.spi.QuerySpace → org.hibernate.sql.ast.from.TableSpace

      • etc..

    • etc..

  • need to investigate the impact on counter-parts for "result assembly".

  • be sure to test bi-directional "key-many-to-one" references. That is something LoadPlan code does a lot of work to handle properly. Need to find the test that Gail wrote for this.

Alpha2

  • General "literal as JDBC parameter" feature based on SQM? I currently have added this via the org.hibernate.query.QueryLiteralRendering enum and SessionFactoryOptions.getQueryLiteralRendering

  • When not rendering literals as parameters:

    • if they occur in SELECT, wrap in cast function based on Java type (?Dialect-specific?)

    • define a better scheme for rendering these as SQL literals. This could possibly be something like the legacy org.hibernate.query.criteria.internal.ValueHandlerFactory. Another option (my preference), considering literals must be basic types (?allow composites?) is to define a BasicType#getLiteralRenderer (as well as an inverse BasicType#getLiteralConsumer).

  • Be sure to implement Callback handling for "subsequent actions" such as…​

    • follow-on locking

    • join fetch conversions to subselect fetches - immediately improves our subselect fetch handling simply by having a SQL AST so we can know what to build the "subselect" based on - no more bug-prone String manip.

  • dynamic-instantiations selecting an entity reference as a ctor argument - we will change to interpret this as (1) fully select (no implicit fetching) that entity and (2) look for constructors with arguments of the same castable type as the entity; for the short term we will have a backwards compatability flag for the old behavior, but using it should log a "deprecation warning".

  • Drop old QueryTranslator and both impls

  • Finish removing #fromString and #toString impls from various BasicJavaDescriptor impls and (use the default impl) move handling of String-based conversions into #wrap and #unwrap. Tedious task, so adding a todo note here - bu partially done.

  • Parameterized ScrollableResults signature - change signature of row access methods or add new row access methods?

  • Redesign Cache SPI as per https://hibernate.atlassian.net/browse/HHH-10707?focusedCommentId=84079&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-84079 and https://gist.github.com/sebersole/2c9ad6b77ea3477ba508c21c6ab61b8d. See https://hibernate.atlassian.net/browse/HHH-11356

  • Change how we handle boolean/Boolean types in terms of JavaTypeDescriptor, specifically how we convert them to/from their representation in the database (most databases do not support a boolean data type) such as 1/0, 'T'/'F', 'Y'/'N', etc. The initial design plan is to leverage AttributeConverter on the Navigable for this purpose:

    • If the user has attached an AttributeConverter to the attribute we’d simply use that

    • Otherwise, we’d look to a config setting that tells us the true/false storage values

    • Finally we’d ask the Dialect

Beta1

  • Find incubations and evaluate for promotion

Should

Should indicates items that should get done for 6.0. Again, some may get pushed to a future 6.x release as resources dictate. As we move along development for 6.0, these items will get scheduled appropriately.

  • Find deprecations and evaluate for removal. This should be done asap to allow for adopter feedback.

  • Move org.hibernate.secure to org.hibernate.resource.jacc? - https://hibernate.atlassian.net/browse/HHH-11478

  • Move org.hibernate.jmx to org.hibernate.resource.jmx? - https://hibernate.atlassian.net/browse/HHH-11478

  • Remove HQLQueryPlan and current QueryPlanCache - see org.hibernate.query.spi.SelectQueryPlan and org.hibernate.query.spi.QueryInterpretations. Determine what to do with org.hibernate.engine.query.spi.NativeSQLQueryPlan.

  • Consider dropping org.hibernate.cache.spi.QueryCache in favor of direct coordination between:

    • org.hibernate.cache.spi.QueryResultsRegion

    • org.hibernate.cache.spi.UpdateTimestampsCache

    • a new "results validation checker", something like:

      interface QueryCacheResultsValidator {
	boolean areCachedResultsValid(
			UpdateTimestampsCache timestampsCache,
			Set<Serializable> spaces,
			Long timestamp,
			SharedSessionContractImplementor session);
}

  • Another literal related idea is to simply not render them into the SQL but instead transfer them directly to the currentJdbcValues array. That obviously only matters when literals are used in the SELECT

  • Remove org.hibernate.engine.jdbc.cursor.spi.RefCursorSupport. Since we already baseline on Java 8there is no need for the reflection anymore

  • Redesign org.hibernate.cache.spi.entry.CacheEntryStructure and friends (with better names) and make more efficient. At the moment, to cache, we:

    1. Create a "cache entry" (object creation)

    2. "structure" the "cache entry" (object creation)

    3. add "structured data" to the cache.

      Would be more efficient to combine (a) and (b). Both are controlled by the persister anyway

  • Handle org.hibernate.query.QueryParameter#allowsMultiValuedBinding for criteria queries

  • While building Metadata during bootstrap, it is important to minimize Class loading - at least on the application ClassLoader (we can always safely load things on the "JPA temp ClassLoader"). To that end, the general process for determining the type of an attribute should be something like:

    • (Create HCANN such that it prefers the JPA temp ClassLoader if available. See BootstrapContextImpl#generateHcannClassLoaderDelegate)

    • When we get an XProperty from HCANN check it for any of the annotations that indicate that this is a non-basic and non-embedded attribute. The reason we check is that JPA says that any attribute not otherwise annotated is considered a basic attribute; however Hibernate does allow this for embedded as well - the Embeddable Class should not be loaded either.

    • If the attribute is deemed to be Basic then build the SimpleValue and pass in the "SiteContext" encompassing the XProperty.

      • At this point it is safe to load the Class of the XClass from XProperty#getType at any time we need.

      • Specifically, we would need this eventually to resolve the JavaTypeDescriptor, but again, we should delay this because later-known additional info could adjust the JavaTypeDescriptor we want to use. Or is this all relative to the "SiteContext" and any information already known (config values, e.g.)?

      • See if the SiteContext indicates a particular SqlTypeDescriptor. If so, use it. If not, ask the JavaTypeDescriptor for its #getJdbcRecommendedSqlType and use that.

      • and so on..

Could

These are things that could be done, and that might happen in 6.0 or it maye happen in 6.x. We just are not sure yet.

  • Do we want to expose some form of Returns from Query objects as a sort of "result metadata"? This would play the same role that Query returning Type does now (but Type is too limiting hence its removal)

  • Allow "Java ServiceLoader" lookups to find contributors

  • Drop support for loading an entity by passing the instance to populate ("optional entity instance" et al)

Won’t have ()

These are things we fully expect to not be in 6.0, alpha or otherwise, but that we want to implement. They might be done in 6.0 (again if resources allow), in 6.x or some > 6 release.

  • Session#stream API - accepts entity to stream, operations on the stream get translated to SQL up until a forEach etc call

  • Consider splitting AST visitors/listeners into smaller pieces. Good article on the subject → http://jakubdziworski.github.io/java/2016/04/01/antlr_visitor_vs_listener.html

  • Consider a common "model walker" useable for org.hibernate.mapping model as well as org.hibernate.persister via visitation contracts implemented in the tree + an external visitor. This would also fit with users being able to do walk model using a custom visitor. Not sure this is feasible or even desirable.

  • org.hibernate.tuple.ValueGenerator currently only works with temporal values. We need to extend that to also work with numeric values (for full "version" coverage). Add a #seed method with a default impl (Java 8 ftw!) that simply call #next. This affects legacy uses of things like DbTimestampValue

Open questions

Unresolved/undecided design questions.

  • Should org.hibernate.mapping.SimpleValue just implement org.hibernate.type.spi.BasicTypeParameters? ATM I create an anonymous inner class, but SimpleValue implementing BasicTypeParameters would save an object creation every time we need to resolve a BasicType. This part of the design is still fluid, so this may not be pertinent as we further implement this. @andrea @chris

  • JTD#toString(Object), JTD#fromString(String), BasicType#toString(Object) and BasicType#fromString(String) all seem worthless. Can these just be handled via JTD#unwrap and JTD#wrap? May be a performance impact , but really…​ where are these used/useful? Although WrapperOptions does come into play.

  • Should we drop JTD#areEquals? That is really the same thing as JTD#getComparator().compare() == 0. Assuming JTD comparator is never used for identity-based comparison.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment