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, Evan [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