Skip to content

sujith-mn/composited-keys-poc

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

21 Commits
 
 
 
 
 
 

Repository files navigation

Composited keys POC

This proof of concept will try to adapt the current devon4j and CobiGen structure to a more generic one that will allow with few changes to adapt the type of id so it can also admit not only Long but also EmbbededId objects.

POC description

The relationship chosen for the POC is a OneToMany between Employee and Phone. Employee being the entity that has the Composite Key as an id and Phone being a normal entity that uses default devon4j/CobiGen values (Long id).

Table 1. Employee
PK/FK Name Type

PK

companyId

VARCHAR(10) NOT NULL

PK

employeeId

VARCHAR(10) NOT NULL

modificationCounter

INTEGER NOT NULL

name

VARCHAR(255) NOT NULL

lastname

VARCHAR(255) NOT NULL

Table 2. Phone
PK/FK Name Type

PK

id

BIGINT NOT NULL AUTO_INCREMENT

modificationCounter

INTEGER NOT NULL

number

VARCHAR(255) NOT NULL

description

VARCHAR(255) NOT NULL

FK

companyId

VARCHAR(10) NOT NULL

FK

employeeId

VARCHAR(10) NOT NULL

Changes done to the devon4j structure in the poc:

In this commit the different changes that were done to the devon4j structure can be seen.

List of the classes changed:

  • ApplicationEntity

  • ApplicationPersistenceEntity

  • BinaryObject

  • BinaryObjectEto

  • BinaryObjectEntity

List of the classes that couldnt be changed and had to be recreated:

  • AbstractEto: This class couldnt be changed because its on the internal parts of the devon4j structure. In order to be able to do the poc, a substitute called AbstractGeneriEto was created to replace it.

Generated classes:

Since this change doesnt break the devon4j structure, the default entities with Long can still be generated, allowing for change only when its necessary. In order to do so, the following changes to the classes when they get generated are necessary:

For purpose of an example we will use "Name" as a substitute of the entity/table name.

NameEntity(entity):

public class NameEntity extends ApplicationPersistenceEntity<Long> implements Name<Long>

Name(Interface of the entity):

public interface Name<T> extends ApplicationEntity<T>

NameEto(Eto):

public class NameEto extends AbstractGenericEto<Long> implements Name<Long>

Extra things done to allow for a CompositeKey

Creating the CompositeKey Object

In one hand, by default the CORE side of an application of devon4j cannot have access to the API part. On the other hand, the CORE has access to the API. This fact will generate some difficulties due to:

  • In the api, i cant use any annotations due to the library only being allowed to be used in the core. This immediately closes the possibility of only creating a the CompositeKeyObject in the API alone since the '@Embeddable' annotation is necessary for an @EmbeddedId to work.

  • Creating the object in the core would not allow for some of the API side classes to access it like, for example, the ETO.

The only solution that was found, was to create a class in API that will be extended by the one at the CORE. This will allow to pass from one to the other one by creating objects.

All these changes, together with the changes that were needed to use a compositekey are on the following commit

About

Composited Keys PoC for devon4j and CobiGen

Resources

Code of conduct

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 94.9%
  • TSQL 4.5%
  • Other 0.6%