persisting a hash map...

[Eric Geordi]

Hey Chris, Jeff,

Our repository is internally stored as a hashmap. Is there an eclipse mechanism for persisting this hashmap between sessions of Geocraft as part of the workspace and for restoring its values in the repository view ?

Thanks,
Eric

[Yonghe]

It sounds like that it should be a job of Java Persistence API rather
than Eclipse.

[Dan Dromereschi]

EclipseLink is the Eclipse implementation of JPA, but I'm not sure it will work for this use case. http://www.eclipse.org/eclipselink/

Dan

[Eric Geordi]

Yeah I found this as well and was looking into how Eclipselink could be applied for the repository

[Jeff McAffer]

EclipseLink is the reference implementation for JPA2.  This however may be way overkill for what you need.  How big is the repository expected to be in real life?  Are you interested in somehow indexing the values or just storing them as blobs?

Jeff

[Eric Geordi]

I think the repository could be potentially large in real life because there are an unlimited number of entities that the user could load, especially if those entities are automatically created as output from some of the algorithms (like the cascading algorithms).

As far as how to store them, I think a blob would be fine because the repository could initially just retrieve the hashmap wholesale (if a previous session exists). And persist it wholesale upon exiting the workspace.

Everyone, feel free to jump in and correct me if I've made the wrong assumptions here.

Thanks!
Eric

[Duncan Child]

Just to clarify things - you only need to persist sufficient
information to reload the data from where it originally came from.

So if a user loads a 1TB file you only have to persist the filename
and related meta data (eg data units) and you don't have to persist
the 1TB of data.

Duncan

[Jeff McAffer]

Cool.  That is what I was hoping for.  So we just have to understand how many entities is reasonable to have in on repo.  We might also consider what to do with the intermediate results.  If they stay in the repo without any sort of marker flags then the repo will grow monotonically and eventually blow up.  Perhaps these can be marked as "transient" or some such and get garbage collected or thrown away at the end of a session.  Need to corelate that to what is on the disk but that's the general idea.

So unless you are considering many thousands of entities to be realistic, some simple storage mechanism should work.  Simple XML format file?  properties file? (depends on the metadata you want to store as well).  It also matters how often you will want to persist the repo storage.  If you want to do that every time something is added/removed to/from the repo then an incremental storage mechanism is desireable.  If you are happy with save on exit or some such then simple is your friend.

Jeff