skunkiferous / meta Goto Github PK

The Meta project actually defines two APIs; the "types" API and the "infrastructure" API.

While the type API is our first priority, we should still try to implement the infrastructure API, so we can sue it when the time comes.

Once we have support for OSGi, we need to be able to generate graphs for individual bundles, but merge them at run time.

That is, we must generate a separate graph file for each bundle, and save it within that bundle, but when actually using the bundles, even before loading the classes, we need to load those XML files, and merge them into one big graph. This is so, because we might want to do bytecode manipulation of the classes at load-time, based on the XML.

To make sure that the recorded schema information is "sufficient", we should define an API that can generate the Java code representi8ng the schema, including such things as "primary key" and toString and hashCode and equals, and maybe even compareTo.

The generated schema (I suggest mutable objects with all public fields, and no getter/setter) could then also be used for data-migration, if it contains the de-serialisation code.

We need to make sure the code works in OSGi (class scanning needs to be replaced)

And we need to extract real bundle, feature and dependencies information.

The first and foremost reason this API was created, is to simplify the persistence of the data. So we must evaluate and update the API, to include all info relevant to serialisation. Since we will have multiple serialisations (over the network, and in the DB, and maybe even more), we must try to keep the information general, so the same meta-info can be reused in all serialisation/persistence contexts, if appropriate.

This should also replace all annotations used in LessObjects.

We must generate a graph file for each bundle at compile time, in Maven, and save it within that bundle's jar. Either with a fixed path, or by specifying the path to it in the bundle's manifest.

We must extend the Type and/or Properties to allow specification of what forms the ID of a type, if any. If the type represents a possibly abstract "entity", then it needs some ID.

But IDs are not a one-size fits all, and so we need flexibility. The ID can be a single property, or a combination of properties. And it can be fully specified by the type itself, or build upon the "parent" ID. Finally, there might even be multiple IDs, and the "scope" of each ID might be the same, or different.

The part of the API that deals with that must support all those types of IDs. And since some of those the IDs form the database keys, we need to be able to specify all the information needed to generate the database keys from those IDs, and build queries based on those IDs.

If we build graphs of OSGi bundles, since those are loaded dynamically at runtime, we might need to build the graph for each bundle first, and then inject it on the global graph, resolving dependencies in the process.

Many problems in the code have been noted as TODOs.
They need to be turned into issues, so they can be prioritized.

Global schema versioning might be the safest, but to support automatic schema migration on load would cause much to much code generation.

So we should have per-class version, so the schema migration code need only to be created per class change, not per global schema change.

A critical feature of the schema API is that it should be able to load old schemas.

This requirement means that we must be able to load schema relating to classes that are not currently available, or have changed. Therefore the requirement of a reference to the real class cannot hold anymore.