Re: [Orekit Developers] Dataloader Project

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

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

> Hello everyone,

Hi Bob,

> Today is the start of June and thus the start of my contribution through
> SOCIS on Orekit!

Welcome !

> My current proposal towards Database support is an extension of the current
> API to incorporate a message digest of the inputstreams that are used to
> parse data. This digest (simple SHA-1 hash) will be used to identify the
> source of the data and will be stored with the data in the database.
>
> I would prefer a design shown in the attached diagram for this, if this
> design is not to intrusive then I propose that I'll make a draft of the
> database storage application using the design shown in my original proposal
> and see how it goes.
>
> If the sources of data are not important towards the correctness of the
> data (e.g. we don't have to warn users of the database application that (1)
> the file is already used to load the data or (2) an entry has already been
> added from a different source) then we can drop this functionality and move
> on with the database storage.

I don't understand yet the purpose of this digest. Could you elaborate  
on this?
Currently, as most of the data loading is done under the hood, the  
user is not really aware of it. Users mostly configure the  
DataProvidersManager and forget about it. In rare case, they also  
configure a few regular expressions to restrict loading to certain  
files when several formats are supported. In other rare cases, they  
retrieve the list of already loaded data from the  
DataProvidersManager. They often access neither the loader nor the  
loaded data, so I'm not sure when they should get the MessageDigest  
and for what purpose.

For now, we let the consistency of the data set under the  
responsibility of the user and did not provide any way to control it.  
So if your proposal adds this feature, it may be an interesting  
addition.

In your class diagram, could you also explain the separation of  
loadData (which already exists in the interface) and processData  
(which is new). Is it related to the database access?

> I have mentioned this before in my proposal but what is the preferred
> persistence API? In my opinion, JPA is most accessible and known to Java
> developers. There is however a large group of developers that dislike the
> ORM approach.

You initial proposal has been seen only by the committers, it was not  
made public before the students were selected. Now that this part is  
done and you are here with us, you can send it again to this public  
list. I'll wait for this to be available to everyone before commenting  
on it.

best regards,
Luc

> ---------
>
> With the feature discussion out of the way I would also like to ask some
> practical questions. As you have noticed by now this e-mail has gotten
> rather large. I'm a fan of reporting very frequently and would like to
> continue to do this. What kind of schedule would the Orekit developers
> prefer (weekly, bi-weekly, daily) and where should I report (mailing list,
> forge documents/wiki)?
>
> Thanks!
> Bob



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