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. > > > 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? > 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). Jonas > Jesse > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
