[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Re: "Reset" action for catalog
|
Hi Adrian
I am trying to remember what happens with the "Reset" menu entry gets
called - :-D
As I recall this was something I did quick so that we could kill a
broken Postgis connection. It is supposed to replace the DataStore used
with a new one. I called it "Reset" rather then "Reconnect" because I
wanted it to sound more serious (because it is).
You are correct that this whole thing is to prevent you from having to
relaunch uDig.
Rest of the comments inline ....
I'm trying to understand what happens when the "Reset" menu entry gets
called on a PostGIS database catalog entry. That's led me to the
net.refractions.udig.catalog.internal.ui.actions.
class which lists you as a (the?) guilty party.
1) On line 72, what's the TEST: java construct? It looks like a case
statement but must be some 'named block' semantic.
Indeed it is.
2) Same line, why are we looping again over the IService since we are
already looping over the IService? Can the ServiceFactory really find
more than one IService with the same ID:ConnectionParmeter set? Would
this only be true in the case where we had just cloned a catalog entry
(possibly for later modification)?
It can actually find many services for a single location - if you just
specify a host name it will try the range of WFS, WMS, PostGIS etc...
and perhaps return all three!
3) There's a nasty warning in
net.refractions.udig.catalog.IServiceFactory#acquire(
URL id, Map<String, Serializable> params )
which should be fleshed out a little. What can go wrong? What should the
coder look out for?
Cool - the danger is based on what uDig uses that URL id for. It is
supposed to be an *exact* match with the data being represented ...
using this method you could confuse the system by creating an IService
with an ID that does not reflect the data being used. So this is fine
for changing the username/password used to connect to PostGIS, or
changing some of the settings (louse bounding box etc...), ... these
things are configuration.
It would be bad to use this to change from a PostGIS to a Shapefile ...
this is more data definition.
I really wish the seperation between configuration and definition was
more clear :-( Something to keep in mind for the future.
4) Where is this method actually implemented? It seems to be the method
that should retry to connect to the database. Currently if uDig starts
and the user then launches the DBMS with the PostGIS Db, there is no way
to re-connect to the tables. Also, I am starting to believe that once we
loose a connection, the only way to re-establish it is to re-launch uDig
and that may not even work in all cases (I have not yet worked
exhaustively to discover the different scenarios and their
consequences).
We have no method to "retry" anything; the only thing we can do is
remove and replace :-( So "reset" using the exact same technique as
when we first start up.
We can do this; the Map will look up the Datastore in the catalog; and
the map is told with an event that the datastore is being replaced (so
it has a chance to remove and FeatureSource's it was working with).
Jody
