gemini-projects / gemini Goto Github PK

A singleton Entity is a one record Entity, where we can only GET and PUT. No POST and DELETE are allowed. Todo:

• DSL new ENTITY Type
• CORE persistence and APIs (no delete or new one, only modify and get)
• Special API handling (no POST and DELETE)

EntityManager should be improved with better documentation. All the undocumented GET APIs should also add the EntityOperationContext in their signature to enable future use (like the other APIs).

Need a way to limit operations on APIs accordingly to User roles. TODO:

• define the model
• define a way to identify the user role and integrate with OAuth2

We could use different strategie here...

For example bind in some way the OAuth2 scope concept to one or some user role. Or handle the RBAC to work only inside the core Framewoek accordingly to the logged user role decoupling role/scope and access_token. This mean that no OAuth2 scope are used, instead all the logic is made by Gemini core by using user roles.

Entities can have multiple logical key but at the moment the is a lexicographic order. Need to specify the order on DSL and implement it in the Core Entity Manager and API Paths.

For example:
ENTITY MultipleLK {
TEXT lk *1
TEXT lk2 *2
NUMBER a
}

*1 and *2 give the order

All the operations like ADD / DROP column and modify an already existent table must be checked with unit and integration tests.

Need to update the OpenAPI Spec generation for Singleton Entity of #1

Need a way to avoid to bind unnecessary METHOD to Entity.

For example with singleton Entities of #1 the POST / DELETE method should be not allowed.

There is always a single record for that entity returned by the GET on entity root path (no need to have logical key).

Add also the actual record if exist.
Now we have only PK and LogicalKey references. If the Reference is created with a real EntityRecord we can store it.

Using the feature implemented in #1 make the openapi documentation info configurable.

In a singleton entity put all the information needed and the refactor the default.

REST design tells that PUT should be used for full replace (all fields) while PATCH is used to make changes to part of the resource.

Add PATCH to separate behavior?

Each Gemini module should provide its OpenAPI spec file in addition to the ALL spec.
RUNTIME became a special module and a special spec file.

The EntityOperationContext should be added to all the methods of EntityManager. API Controller then can inject for example the user to be added on meta record informations.

Need to move the closedDomain configuration in DSL or another settings. Or change the initschema handler.