Description

One of the (most likely) next steps of dividing the API is to split the API module (rookit-api-dm) into two modules: one for the Storage API and another for the Data Model API.

Trivially, the Storage API module would depend on the Data Model API module. However, due to the fact that Dynamic Playlists currently depend on the Storage API (i.e. TrackQuery), we cannot modularize these APIs.

Solutions (and random thoughts)

• Decouple TrackQuery from Dynamic Playlists by creating an abstraction
• Maybe this problem exposes the fact that the notion of query is not bound to "storage", which may imply that querying should have its individual module. However this very hypothetical solution would still have a cyclic dependency.
• Maybe Dynamic playlists should be in a separate module from the rest of the Data Model, with the following dependencies:
  • Data Model API (top module)
  • Storage API -> Data Model API
  • Dynamic Playlists -> Data Model API
  • Dynamic Playlists -> Storage API

Dependabot couldn't authenticate with https://jitpack.io.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

TBD

Dependabot couldn't authenticate with https://jitpack.io.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

You can mention @dependabot in the comments below to contact the Dependabot team.

Context

Property getters (denoted by @Property) and property setters are implicitly linked. Note here that a property getter can have 0..N property setters:

• No property setters for final properties
• One property setter for "common" properties
• Multiple property setters for special types such as Collection

Generation possibility

Up to this point, this line of throught leads us to the possibility of having a generation process for property setters. However, as property setters are to be included in an Entity's upstream hierarchical tree (as it is done today), it is Impossible to create a functional solution (AFAIK).

Validation Alternative

Since property setters can be derived from getters (just like filter methods can be derived from property getters), we should have an annotation processor whose job is to validate if property setters are correctly declared. This way, we can still force a predefined convention, without the need to get into more shadier strategies of coding generation.

As the storage API is implicitly derived from the data model API, we can, and should, use an annotation processor to generate the first from the second (with some exceptions). Hence, there should be a new module which is responsible for generating said API.

At this point, the candidates for generation are:

• [Todo] DataStores: Datastores act as storage managers for entities. They extend a base parameterizable DataStore, in which they simply resolve such parameters. DataStores are only generated for:
  • @Entity: These act as the main datastores
  • @EntityExtension: Entity extensions also need a dedicated datastore, as general EnTityExtension queries do not inherit from EntityQueries. Despite this, by default, entities and its correspondent extension should share the same datasource (i.e. an entity datastore reads and writes from/to the appropriate entity extension datastores).
• [Done] Query: TBD
• [Done] Filter: TBD
• [InProg] Update Query: TBD
• [InProg] Update Filter: TBD

By looking at TrackKey for instance, we see that it refers the properties from VersionTrack, which is not scalable, due to the fact that if tomorrow someone wants to create a new extension for Track, they would have to also update TrackKey with the additional properties from this extension.

Pretty much self-explanatory. The method creates contains a single parameter whose name os the "raw" property type, not applying the correct naming policy for java method parameters.

The API should always be based in usability, which sometimes may imply some redundancy and "copied code" from multiple sources. One of the greatest limitations IMO to achieve a good API is laziness (originated from boredom/lack of a challenge). As such, we should try to generate as much API code as we can (as long as it doesn't actually make the API less usable).

The solution implies the refactor of the current module (rookit-api) into a tree of submodules:

• rookit-api
  • rookit-api-dm
  • rookit-api-auto
    • rookit-api-query-auto
    • rookit-api-convention-auto

Dependabot couldn't authenticate with https://jitpack.io.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

You can mention @dependabot in the comments below to contact the Dependabot team.