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

Re: [Orekit Developers] Database Support Progress

Hi Bob,

I read through your report, and you might want to look at mockito [1]
(if you haven't already) to help create mocks for testing. I've used it
writing unit tests for other projects and it makes it easier to test a
single class at at time. I've even used it to track down a few bugs in
Orekit itself. Though Orekit only has JUnit as a test dependency, you
could add mockit as a test dependency to the new maven projects you create.

Best Regards,

[1] https://code.google.com/p/mockito/

On 07/16/2014 12:51 PM, MAISONOBE Luc wrote:
> 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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature