[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Database Support Progress

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


Hello everyone,


Hi Bob,



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.
There is one thing that is unclear to me. Your proposal seems to imply that random user will want to do both read and write at the same time (i.e. to persist data by themselves). The read and write aspect should really be separated. In fact, current Orekit *never* writes, it only loads data. so the "write" part should be outside of Orekit, in a separate application, dedicated to initialize or update the database. What should remain in Orekit core is the ability to read (i.e. some improvement of the data loaders for database use).
So we would suggest three different parts (say three maven or eclipse projects) : 

 - one would be Orekit itself, with new connectors to load from a database
 - one would be an application that does implement a connection to
   a specific database to load from it (i.e. it would be a prototype of
   what a user who wants only to read from its database would do), of course
   this part would depend on the former part
 - one would be a writer that can populate a database.
I don't understand the configuration part. Do you want to have something flexible enough that simple configuration would allow to switch from one database scheme to another one? This would probably be over-engineered. We don't "switch" from one configuration to another one, but users may need to set up way to connect to their database, and then they will stick on it for a few years (space industry is really conservative). So if "configuration" is "develop specific code that implements a general interface", it's OK with us. If configuration is "write an XML/JSON/TXT file that describes the scheme and will be loaded automatically by a magic class that understand everything possible", then it's probably too complicated (and hackish as you write). Currently, when users need to have a specific loader, they develop it. We provide a set of current ones that meets general needs and use canonical files as they are provided by laboratories (IERS, JPL, ...). When specific ground systems prefer to use their own format, they simply develop code for that, they don't "configure" a general reader. 

So I would suggest to simplify a little the design.
As per testing, try to select a simple reasonable goal. It's OK to use one implementation (in-memory if you want) and avoid developping yet another layer to isolate everything from implementation. 

best regards,
Luc





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





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