What do I do with a contribution in a version where a contribution is not needed (there are no logical changes to connect)
For example, imagine a Party object which is stored in a version in a versionedparty, and that party has no other related information, so the Contribution is useless.
The problem is that in a Version an Objectref to a Contribution may not be void, and that in a Contribution a set of ObjectRefs may not be empty.
A contribution is required for any change made to a repository whether it be one object being added/modified or more (i.e. a contribution is always needed). See it like a revision in Subversion, a new revision number is assigned even if you commit only one file.
A contribution is required for any change made to a repository whether it be one object being added/modified or more (i.e. a contribution is always needed). See it like a revision in Subversion, a new revision number is assigned even if you commit only one file.
Thanks, that is a very clear answer. I understand its function.now. Maybe I have another small question in this cotext later, but I am now working on something completely different
Bert
I would like to know if is there any planning regarding the
implementation of a persistence layer and a AQL query interface on the
Java project . Best Regards , Gonzalo Tirapegui Medina.
I don;t know if there is a plan for publishing a persistence-layer. But, I would not advise to wait for that.
Let me explain my opinion:
A simple persistence layer is easily build with, f.e. Hibernate, or XML or other object-serializers.
If you keep your interface to your persistence layer clean, than you can concentrate in a later stage to a more efficient one.
In my opinion, hibernate, and other quick solutions are good for fast development, and easy maintainable code. Which is good for applications which tend to change sometimes in their persistence-structure, most applications do.
But one power of openehr is that the persistence/reference model hardly ever will change, because, it are the archetypes which form the datastructures without change in the persistence layer.
This fact makes it posible to concentrate on a highly optmized peristence.
But to get started, you can build your interface to an easy persistence layer, and what happens below, you can regard as something to do later.
Once you realize that it is all in your hands, and that the kernel/peristence layer will stay very stable, for years, you can start a completely new way of application building, and skip the easy methods and switch to very detailed optmizing, and come to a better performance than ever was possible before.