On 1-Apr-06, at 4:43 AM, Jonas Johansson wrote:
Thanks for the info so far! Comments below...
Jonas
On Fri, 2006-03-31 at 11:23 -0800, Jesse Eichar wrote:
On 31-Mar-06, at 10:17 AM, Jonas Johansson wrote:
Hi again,
I have a question on MemoryDataStore persistence between sessions
(or
whatever the term for quitting uDig, saving workspace and loading it
again).
Since the MemoryDataStore shows up in the Catalog with the layers
that
existed before quitting (but with all features gone when doing
Feature
Count and CRS unknown when doing Resource Summary), I figure there
must
be some persistence after all.
This is where you can help write history. How and what is persisted
is still kind of being determined. Here is the current plan more or
less:
On quitting uDig a user will be prompted to save the memory layers.
If they are saved then the layers in the map will be replaced with
the persistent layer. (For 1.1 you will only be able to save to
shapefile but later version will provide a choice).
Here are some choices, but will be settable in preferences
1. a) If the layer isn't saved it stays in the map and will be part
of it the next time uDig is loaded (obviously without the features,
but sometimes it is the Featuretype that is important)
b) the layer is removed from the map.
2. a) Everytime uDig is shutdown the memory datastore is removed
from the catalog
b) The memory datastore and its resources are left in catalog
for later use. Again users might not want to redefine the features
types.
By default I'm thinking 1 b) and 2) a) will be used. What do you
think?
Hm.. I would have guessed that, since the MemoryDataStore is
supposed to
be temporary, it should be removed when a session ends (2 a). All
layers
and features will be lost unless a layer was exported/saved to some
other stable storage. Doesn't feel temporary if FeatureTypes/layers
remain, unless the workspace is considered temporary storage.
Fair enough
When in the second session, I check the Catalog and get a
MemoryServiceImpl as "resolve" and it turns out that it can not
resolve
to a IService, and not resolve to a DataStore. The same goes for my
WFSServiceImpl so I guess there is nothing strange with that.
I'm not sure what you mean here. You can get the members of a
catalog and one should be a MemoryServiceImpl. Although you should
do you search by checking which service can resolve to a
MemoryDataStore because we will probably hide MemoryServiceImpl so
you can't check for that.
However, the MemoryServiceImpl can resolve to a MemoryDataStore. So
the
question is, how do I get to pick up that MemoryDataStore and use
it as
an IService like I did in the previous session? It doesn't seem
to be
able to adapt itself to a IService....
A MemoryDatastore cannot adapt to an IService it is a one way
street. You can to get the IService and keep the reference. What
You say "You can to get the IService and keep the reference." - hm,
something wrong with this sentence =) "You can't" or "you can"? How?
I mean that you have to keep the reference to the IService because
you can get it from the MemoryDataStore
are you trying to do here?
I'll try to keep it short. Basically what I want is to find a nice way
to use the same MemoryDataStore between sessions (since right now it
actually shows up in the catalog in the next session). In my case I
guess it is 1 a) that happens, and I would be fine with that as
long as
I can add new Layers to the map and add new Features to the
MemoryDataStore.
I need to be able to create new FeatureTypes because of possibly
buffering features with different CRSs. For a new FeatureType I
want to
create a new Layer in the Map. As I understand it, the way I create a
new Layer in the Map is using
map.getLayerFactory().createLayer(newFeatureTypeIGeoResource);
and this means that I have to have a IGeoResource that is a handle
to a
FeatureStore that writes the new FeatureType.
Now, in the first session I created my MemoryService by doing
basically
IGeoResource res = ....createTemporaryResource(bufferType);
Then I could get the IService with
IService service = res.parent(...);
Having the IService handle allowed me to get a list of all
IGeoResoruces.
In the second session, how do I create a new Layer if all I have is a
MemoryDataStore with no possibility of getting it coupled with an
IService handle and therefore no possibility of getting a new
IGeoResource that matches my newly added FeatureType/Schema to the
MemoryDataStore using
dataStore.createSchema(bufferedType);
and then
IService.members()
to get a list of its IGeoResources and finding the one that matches my
new bufferedType?
Can I handle these things by only using references to DataStores (not
IServices) and FeatureStores (not IGeoResources) so that it works the
same way between sessions? But then again what is the point of having
IServices and IGeoResources at all if I cannot even create a new
handle
(IService) for a MemoryDataStore in the next session? There must be
some
way of doing this nicely that I don't know about...
A problem I have is that the MemoryDataStore that is still in the
catalog in the next sessions causes an exception to be thrown if I
create a new MemoryDataStore. And since I don't know how to reuse the
one in the catalog, maybe I should just always remove the
MemoryDataStore in my BufferPlugin stop() method so that I can always
create a new one in the next session and the old one won't be in
the way
(2 a).
I see. Ok so I think I will make sure that the memory data store is
cleaned up on shutdown.
How about in the start method you remove the MemoryDataStore service
from the catalog until I get this done.
Jesse
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
