blazebit / blaze-domain Goto Github PK

Add support for collections that have no element type. This is useful for functions that accept any collection type.

Migrated from Blazebit/blaze-notify#22

I would count the exists predicate into the COLLECTION predicate types class. The use could look like this EXISTS (document.users.email = '[email protected]' AND document.users.active)
The parenthesis are optional for a simple predicate but necessary if composite predicates should be considered in the exists predicate.
The semantics of this could be WHERE EXISTS(SELECT 1 FROM document.users u WHERE u.email = '[email protected]' AND u.active = TRUE).
I would work on the query translation to make this work properly as I think this will be a very helpful tool for many use cases.

CollectionType should extend from a new type ParameterizedType, to allow modelling more complex types like e.g. Map. The idea is, that ParameterizedType has N parameter types and CollectionType is a special variant of that, because it has the notion of an element type.
When doing that, there also needs to be a way to register a "TypeFactory" for such custom collection types, which will produce ParameterizedType instances. We should try to model collection types through that same mechanism.

In order to be able to use domain functions in a safer manner (currently some use untyped arguments), it would be good to introduce union types for domain function arguments. I don't think it makes sense to support union types anywhere other than there. It's probably best to create a subtype of DomainType that model this. The domain type has a special name, which we then use for arguments. We need to check though, that only domain function arguments can use union types.

Currently our blaze-domain code is located in the blaze-notify project. Move it here.

An API that allows to point to an abstract attribute or a concrete element in an object. This is similar to JSONPointer which we want to support for serialization/deserialization.
The default serialized format is the JPAish dot-navigation syntax we use in blaze-persistence and also in the parser for blaze-expression paths.

The ModelPointer can be used to query and write values on actual domain objects via the ModelAccessor API. Note that there already is an AttributeAccessor Metadata API in blaze-expression and the idea is, that the ModelAccessor API is the successor that lives in blaze-domain.

In the end, I want to be able to do simple object graph extraction and altering with just blaze-domain. Some simple ModelAccessors for accessing a Map should also be provided. Note that the ModelAccessor is format dependent, so if we expose this somehow in the API, the format dependence should be encoded into that as well.

Support for instance methods can be a special case of normal functions. We could implement that in the model by allowing to define an invocation mode on functions.
Invocation via instance methods is great for end-users because it allows to discover available methods via autocompletion.

We need an API that allows snapshotting the state of a domain object and create a diff as ModelPatch when comparing with a different snapshot. Finally, it should also be allowed to apply a patch to a domain object.
It would be great if we could support JSONPatch as serialization format.

Allow removing functions and domain types etc.

We need an API and SPI for accessing attribute values of domain objects. A default implementation can use ad-hoc Reflection but we might want to create a static analyzer that creates accessor-classes during annotation processing.

The idea is to provide an API for serializing and deserializing domain objects to some format(csv, excel, json, xml, etc.). This is similar/related to expression serialization in blaze-expression, but in this case is only for domain objects. The serializer contract should offer methods for serializing a header and payload. The idea is that the header only needs to be serialized once and payload can be serialized multiple times afterwards into an existing context.

I have to think more about this, as we might move this to blaze-data. Not sure if it even makes sense to define the base contracts in blaze-domain.

The main driver for this is the serialization/deserialization for the excel format. The implementation should use a library like Apache POI. The domain model contains serialization metadata e.g. @ExcelColumn(index = 1, converter = SomeConverter.class) which is used to drive the serialization. The API should be capable to create a specialized serializer/deserializer for a domain type so that it can spin bytecode behind the scenes if wanted. The converter is very similar to the TypeAdapter contract in blaze-expression, so we might want to lift this contract into blaze-domain.

Migrated from Blazebit/blaze-notify#20

Not only do we need generic function support, but we also need support for named argument invocation. Invoking a subtring function for example can look like this substring(string = document.name, start = 1, end = 20)
Not sure if this syntax makes anything ambigous, but this is definitely something we should look into.

Migrated from Blazebit/blaze-notify#21

When we have the parser rules for #5 we could actually also implement support for entity literals which would allow us to construct composite type literals that might come in handy for things like User(email = '[email protected]') MEMBER OF users

Note that it might be nice if entity literals would be somehow aware of the attributes that are set i.e. User(email = '[email protected]') MEMBER OF users should match by email whereas User(name= 'someuser') MEMBER OF users would match by name. Also allow domain operators on entity types?

We need a TypeScript runtime implementation and a compact JSON serialization format for the domain model. In Blaze-Expression we will use this for editor autocompletion.

Migrated from Blazebit/blaze-notify#4

Based on the model, it should be possible to apply an expression to a criteria builder for filtering.

Migrated from Blazebit/blaze-notify#2

It should be possible to use an interface based approach for defining the models. Ideally, we could integrate with entity views.