[Orekit Developers] Database Support Progress

Hello everyone,

I've attached my new design in the form of another status report to this e-mail. At the end there is a discussion section to highlight some questions that should be discussed on the mailing list.

To answer the last e-mail of Luc in the previous thread, which was the inspiration of this re-design:

So from a persistency point of view, either only one set of parameters is persisted and the converter need to be used upon reloading to fill up the omitted data, or both sets of parameters are persisted and the converter is not used. There is no problem in instantiating this converter (it's a small internal class) and not using it. As the amount of data is not overwhelming (a few hundreds of kilobytes, perhaps a few megabytes at most), I would suggest persisting both sets of parameters.

Agreed.

Concerning JPA, I would prefer to avoid adding dependencies to Orekit. Up to now, there is only one dependency to Apache Commons Math. Users who want database will already have their own set of dependencies (perhaps hibernate or another JPA implementation, perhaps nothing JPA related). Users who do not want it will be annoyed by a big dependency that pulls in a lot of other things and they do not use. In any case, it seems important to me to have this feature implemented in a plugin-like way, i.e. there are hooks in the Orekit core to use it, but users can select what they want.

I propose a module setup for this as explained in the report.

Concerning the data scheme, our way of handling data in Orekit has always been: the data and its format already exist outside of Orekit (perhaps because they are used by other components of the space system), and Orekit should adapt to it. This is the reason why we have lots of data loaders for the same kind of data. If possible, I would like to have it the same way for database, perhaps using some interface that would remain under user responsibility to map the fields (disclaimer : I am not a database specialist, so this may be completely stupid, please correct me if this is too ugly). Would JPA work in this configuration? I.E. would hibernate (or something else) be able to connect to an existing database with an existing scheme?

I hope I meet the requirements with the design in the report, as for JPA, it is possible but I feel the JDBC solution would be prettier. If it would be benificial for the discussion I can make a list of methods how a configurable JPA implementation for Orekit would be but I'm afraid it will be riddled with technical details.

Thanks!

Bob