Documentation fixes, abstract types, referential integrity, embedded document indexes for root record, deletion feedback

[jstuyts]

ArcadeDB is looking great. It allows me to model my domain more naturally than with SQL databases, and the queries are a lot nicer to write too. After some experiments, I have the following remarks.

The version number in the documentation is outdated, and not all of the functionality described in the documentation is available in that version. Also, addParent(...) is still used, but this has been replaced with addSuperType(...).

It would be nice if it was possible to specify that an instance of a type cannot be created. This is great in combination with embedded documents, because it allows modeling sum/sealed types better. I tried to add a BeforeRecordCreateListener to the type that is not allowed to be instantiated, but the listener is not called for embedded documents.

By adding a BeforeRecordDeleteListener it is possible to prevent deletion if 1 or more links still point to the record. It would be nice if there was standard functionality to declare that records pointed to by a specific link are not allowed to be deleted, so you don't have to write each query to detect use by links yourself.

If you prevent deletions using a BeforeRecordDeleteListener, you have to use existsRecord(...) to check if the deletion succeeded. Having delete() return a Boolean would be better.

For the deletion prevention, the links pointing to a record must be found quickly. If a link is in an embedded document that is a sub type of the declared type of the property, how do you create an index for that link? If a create an index for the document sub type, it seems not to be used during the query to find the links:

@Root[prop:EmbeddedBase=@EmbeddedSubType[someLink=#1:0]]
@Root[prop:EmbeddedBase=@AnotherSubType[withoutTheLink=...]]

[lvca]

@jstuyts Sorry for the delay with this response. I see addParent is not in the documentation, I assume it was already fixed after your post.

About your first proposal, looks like we'd need to define a type as abstract, so it can't be instantiated, but only extended by a sub-type. Doable. Also, we could have an embedded: true to avoid creating buckets (files) for the type and new instances of records in the database, but only as embedded.

About the constraint with deletion, we always suggest using the graph model instead of documents with inks. With the graph model, edges take care of automatically managing deletion in a graph without having broken links, or manual lookups in case of deletion. In that case, you can define the BeforeRecordDeleteListener listener by checking that there are no edges (in and out) to allow the deletion, without expensive lookups.