The main advantage that the Jakarta Data specification has is improving ease of development. We need to ensure we have good tooling support around it to ensure that Liberty can do well in this space.
Some ideas are on the Developer Tooling slide (42) of its Upcoming Feature Overview presentation, but these should be seen as a starting point. It ought to be possible to do much more in the tools to help users to intuitively author code in Jakarta Data.
One aspect that we know for certain that we want is the ability to generate static metamodel classes from their entity classes. Note that Jakarta Persistence also has a static metamodel, which is different from Jakarta Data's, so the user will need to be able choose which they want.
Tooling could also generate the start of a repository class for an entity -- automatically adding the @Repository annotation, extending the most feature-rich of the built-in repository types, CrudRepository, (with built-in awareness of the others to switch between), and automatically filling in the type variables with the entity type and id type. It could even automatically compose a few repository method signatures to start with.
Tooling should offer autocompletion of repository method signatures based on the available entity attributes.
First, by offering to create a new method given a particular selection (Entity-based Insert/Update/Save/Delete, Parameter-based Find/Delete, Method name-based Find/Delete/Count/Exists, Query Language, or Resource Accessor method).
Alternately, if the user starts writing any of these types of methods, such as,
Methods annotations @Insert, @Update, @Save, @Delete:
Offer to fill in return type given what is valid for the annotation.
Can default the method name to match the annotation, but in lower case.
Offer to fill in parameter type exactly matching the return type if the return type indicates an entity type. If void return type, then offer valid options per the annotation. If Delete and a boolean or numeric return type, see the next section.
For the @Find and @Delete annotation, after the user chooses the method name and the subsequent ( character, tooling could offer options for method parameters based on the entity properties (if using the -parameters compile option), otherwise offer the @By annotation for parameters, which can be autocompleted with a property name from the static metamodel if available, another otherwise the string name of an entity property.
For Query by Method Name pattern, having detected a method name prefix find / count / delete / exists, offer options for additional method name text based on the entity attributes (such as ById) and then additional options like LessThan) and then options like And / Or / OrderBy / (, and autocompleting parameters based on the entity attributes chosen and their types.
For Query Lanaguage methods, detect the @Query annotation and offer an example of each type of basic JDQL query using the entity properties, making up a method name (if it doesn't already have one) and adding corresponding method parameters, defaulting to positional parameters. If the user writes JDQL with named parameters, autocomplete the method parameters either relying on the -parameters compile option or otherwise use @Param with the named parameter names.
In the case of all three of the above, a method returning Page or CursoredPage should offer autocompletion with a PageRequest parameter.
In all cases where PageRequest or Limit is used, ensure there is either already an ORDER BY clause in the query lanaguage, or an @OrderBy annotation, or a method parameter (can offer to autocomplete these) that is: Order<ENTITY_TYPE> or Sort<ENTITY_TYPE> (if static metamodel available), or Sort<?>... or Sort<?> if there is not.
The OrderBy annotation, which can appear multiple times on any repository find method, can offer autocompletion based on the entity properties, preferably using the static metamodel if available.
If tooling has a way to identify dataSource and databaseStore ids in server.xml config, and/or persistence unit references and data source resource references and DataSourceDefinition names in applications, it could provide suggestions for the dataStore attribute of the @Repository annotation.
For extra credit, tooling could even provide help writing JDQL based on the query language requirements and available entity properties.
I'm sure will be other and maybe better ideas that come up. This is something to start with in considering what is possible.
yeekangc
commented
3 weeks ago
The main advantage that the Jakarta Data specification has is improving ease of development. We need to ensure we have good tooling support around it to ensure that Liberty can do well in this space.
Some ideas are on the Developer Tooling slide (42) of its Upcoming Feature Overview presentation, but these should be seen as a starting point. It ought to be possible to do much more in the tools to help users to intuitively author code in Jakarta Data.
One aspect that we know for certain that we want is the ability to generate static metamodel classes from their entity classes. Note that Jakarta Persistence also has a static metamodel, which is different from Jakarta Data's, so the user will need to be able choose which they want.
Tooling could also generate the start of a repository class for an entity -- automatically adding the
@Repositoryannotation, extending the most feature-rich of the built-in repository types,CrudRepository, (with built-in awareness of the others to switch between), and automatically filling in the type variables with the entity type and id type. It could even automatically compose a few repository method signatures to start with.Tooling should offer autocompletion of repository method signatures based on the available entity attributes.
First, by offering to create a new method given a particular selection (Entity-based Insert/Update/Save/Delete, Parameter-based Find/Delete, Method name-based Find/Delete/Count/Exists, Query Language, or Resource Accessor method).
Alternately, if the user starts writing any of these types of methods, such as,
Methods annotations
@Insert,@Update,@Save,@Delete: Offer to fill in return type given what is valid for the annotation. Can default the method name to match the annotation, but in lower case. Offer to fill in parameter type exactly matching the return type if the return type indicates an entity type. If void return type, then offer valid options per the annotation. IfDeleteand a boolean or numeric return type, see the next section.For the
@Findand@Deleteannotation, after the user chooses the method name and the subsequent(character, tooling could offer options for method parameters based on the entity properties (if using the -parameters compile option), otherwise offer the@Byannotation for parameters, which can be autocompleted with a property name from the static metamodel if available, another otherwise the string name of an entity property.For Query by Method Name pattern, having detected a method name prefix
find/count/delete/exists, offer options for additional method name text based on the entity attributes (such asById) and then additional options likeLessThan) and then options likeAnd/Or/OrderBy/(, and autocompleting parameters based on the entity attributes chosen and their types.For Query Lanaguage methods, detect the
@Queryannotation and offer an example of each type of basic JDQL query using the entity properties, making up a method name (if it doesn't already have one) and adding corresponding method parameters, defaulting to positional parameters. If the user writes JDQL with named parameters, autocomplete the method parameters either relying on the -parameters compile option or otherwise use@Paramwith the named parameter names.In the case of all three of the above, a method returning
PageorCursoredPageshould offer autocompletion with aPageRequestparameter.In all cases where
PageRequestorLimitis used, ensure there is either already anORDER BYclause in the query lanaguage, or an@OrderByannotation, or a method parameter (can offer to autocomplete these) that is:Order<ENTITY_TYPE>orSort<ENTITY_TYPE>(if static metamodel available), orSort<?>...orSort<?>if there is not.The
OrderByannotation, which can appear multiple times on any repository find method, can offer autocompletion based on the entity properties, preferably using the static metamodel if available.If tooling has a way to identify dataSource and databaseStore ids in server.xml config, and/or persistence unit references and data source resource references and DataSourceDefinition names in applications, it could provide suggestions for the
dataStoreattribute of the@Repositoryannotation.For extra credit, tooling could even provide help writing JDQL based on the query language requirements and available entity properties.
I'm sure will be other and maybe better ideas that come up. This is something to start with in considering what is possible.