Re: [Orekit Developers] Database Support Progress

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Bob Reynders <tzbobr@gmail.com> a écrit :

> Hello everyone,

Hi Bob,

> Inspired by the report delivered by Roberta I wrote up a report concerning
> my own work so far.
>
> It can be found as an attached PDF and in summary; it shows two design
> options for JPA and DBUtils (attached seperately as well).

Sorry for the delay in reviewing.

Here is a first quick look at your document, I'll take more time over  
the week end.

Concerning the converter, its use case is the following one. The  
nutation correction information represents the discrepancy between the  
theoretical motion of Earth pole and the true observed values. Legacy  
theory, up to 2003, used two parameters (Delta Psi and Delta Epsilon)  
to compute nutation, and therefore the corrections applied to these  
parameters were delta Delta Psi and delta Delta Epsilon. New theory,  
since 2003, uses three parameters (x, y and s) and the corrections are  
applied on the first two parameters (delta X and delta Y). There is a  
relationship between the two theories and one can compute one set of  
parameters from the other set. Some files only provide one set of  
parameters, but users may need to use the other set. So the  
NutationConverter is used upon loading to convert once what is  
available in the file and to store both representations of the same  
data so it can be retrieved without further computation.

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.


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.

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?

best regards,
Luc

> I propose that I implement basic functionality in the form of unit tests
> with JPA as soon as possible and see how it goes.
>
> PS. I deliberately left out the information regarding the digests of
> inputstreams as this is better discussed as an extra feature in the end, my
> apologies for the confusion earlier.
>
> Cheers
> Bob



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.