Larry wrote: I appreciate all of the clever solutions, but I will
remain convinced that BasicFeature can detect modification without any
need for explicit client methods to set it, until someone shows me
proof that it can not.
I agree with Larry on this point. I believe it would be safe to
An example of the standard usage pattern for JDBC can be seen in:
com.vividsolutions.jump.datastore.jdbc.ValueConverterFactory.
Regardless of whether you use ResultSet's getObject() or something like
getInt(), eventually you are going to need an object representation of
the data in order
I tried Sunburn's mod to BasicFeature and it seems to work.
I looked again at Paolo's mod and it looks like it will work.
I have tested my mod and it seems to work.
Larry
On Fri, May 1, 2009 at 10:17 AM, Paolo Rizzi g...@oicom.com wrote:
An example of the standard usage pattern for JDBC can
It looks like there are several ways to skin a cat! I have no problem
accepting Larry's presented solution, or modifying my solution to
include the method needed to manually mark the completion of feature
intialization.
I am willing to make these adjustments, offer another round of
testing, and
The previous sample code I posted was foolish, I'm sorry!!!
Find attached a better version that uses a single Object reference to
track both initialization and modify state.
During initialization this Object references a byte[] where each element
tracks the init state of the corresponding
An example of the standard usage pattern for JDBC can be seen in:
com.vividsolutions.jump.datastore.jdbc.ValueConverterFactory. Regardless of
whether you use ResultSet's getObject() or something like getInt(),
eventually you are going to need an object representation of the data in
order to work
Larry wrote: I appreciate all of the clever solutions, but I will
remain convinced that BasicFeature can detect modification without any
need for explicit client methods to set it, until someone shows me
proof that it can not.
I agree with Larry on this point. I believe it would be safe to
/30/09, Sunburned Surveyor sunburned.surve...@gmail.com wrote:
From: Sunburned Surveyor sunburned.surve...@gmail.com
Subject: Re: [JPP-Devel] Modifying BasicFeature to track modifications
To: OpenJump develop and use jump-pilot-devel@lists.sourceforge.net
Date: Thursday, April 30, 2009, 7:30 AM
Hi.
What might happen if it is the geometry that is null in the database?
It is rather common situation sometimes, it is quite possible that we
know for example parcel attributes beforehand and we should just
digitise the borders afterwards.
The DB Query plugin (or should those plugins be
From the point of view of BasicFeature, there is no distinction between the
geometry and any other attribute. All modifications are still funneled
through setAttribute(). For example the setGeometry() code in
AbstractBasicFeature is:
public void setGeometry(Geometry geometry) {
I believe Larry is correct. A database null and a null Java
reference are not the same thing. I'm not absolutely sure about this,
but I bet one of our database wizards could confirm.
The Sunburned Surveyor
On Wed, Apr 29, 2009 at 7:44 AM, Larry Becker becker.la...@gmail.com wrote:
From the
Larry,
I wanted to get back to you yesterday, and I got bery busy at work. I
don't personally have a problem with you commiting your changes to the
BasicFeature class. We can start testing the change in our nightly
build, and will be able to get an idea on how serious the memory
impact is. In the
Good one Larry! That seems like a perfect solution...
Larry Becker wrote:
OK, it turns out there is a way to implement BasicFeatue.isModified()
with a simple boolean. All you need to do is add a check for null as in:
public void setAttribute(int attributeIndex, Object newAttribute) {
Good job done!!!
But what if the initial value for a certain attribute was indeed NULL???
Data coming from a database can contain NULLs...
I thought about this problem, but to me there's no way for a Feature to
reliably know when it's initialization ends.
Maybe client code, for its own
In the code inside my previous post I used the value this as a flag
but maybe that was bad!!! That way the BasicFeature could live forever,
or maybe not if garbage collectors are smarter these days...???
Anyway the point was to use a reference to any already existing Object
as a flag, so to
What can I say that I haven't already said? If you have the code I sent
you, I would suggest making modifications to it and see if it works.
Larry
On Fri, Apr 24, 2009 at 5:54 PM, Sunburned Surveyor
sunburned.surve...@gmail.com wrote:
If we are concerned about memory we might try a single
I will do some testing when I get time. If Chris beats me to it as
part of his SoC work, he can run some testing with methods he thinks
might work best.
SS
On Mon, Apr 27, 2009 at 6:12 AM, Larry Becker becker.la...@gmail.com wrote:
What can I say that I haven't already said? If you have the
Larry, can you summarize the proposed change, for the benefit of those
who haven't read all 45 posts?
(Maybe JUMP needs some sort of RFC mechansim...)
I don't understand your comment that If it was per-feature
overhead I thought this *was* implemented per-feature? If not, I
really don't
I see your point, although newly-created BasicFeatures aren't really an
issue - they are always dirty by definition. It's just features which
have had their attributes modified which are the problem.
I'm not totally crazy about this MutableBasicFeature/BasicFeature
dichotomy, but it might be
Maybe it would be possibile to add explicit init methods like:
beginInit()
endInit()
or even a single atomic method:
init(Object[])
So that mod-aware calling code could call them to let the Feature know
it is being initialized.
Still the Feature could manage a disposable
Hi Michaël,
We need to track modifications on a per-feature basis because it is
necessary to update a database source when a modification is done in the
OJ UI : right/wrong
Right.
You propose to track modification on each attribute individually because
you don't want to update a whole
Perhaps you could extend BasicFeature to be a MutableBasicFeature, and
this is the concrete class that would be used by Writeable DataStores.
This is a good idea, but tough to implement. A search for new
BasicFeature found 80 matches in the project. The fact is that most tools
create
But there's something that could go wrong anyway, because an attribute
has a NULL value by default and client code may decide to not set
attributes at all if it has no value to set them to. If this happens,
the Feature could remain not-modified for ever.
This is possible, but not likely.
If we are concerned about memory we might try a single int as a
counter instead of using an int to count mods for each attribute. So
you could do something like this:
// Private member variable to count attribute modifications.
private int attModCounter = 0;
public void setAttribute()
{
//
Larry, why do you use an int rather than a boolean to flag changed
attributes?
BTW, In order to track changes to Geometry attributes correctly, the
JUMP codebase needs to be scrutinized to make sure it isn't mutating
Geometries in place.
Larry Becker wrote:
Hi,
As I mentioned in the
The tricky thing about modifications is not to find a record is modified
just because you set the initial value. It is only modified if you set it
more than once, otherwise all records would be set as modified as soon as
they are loaded.
The next trick is to consider that you call setAttribute
re Mutating Geometry in-place - JTS discourages this, but does not
prevent it. Sometimes people do this when they are transforming
coordinates (eg. translation or affine transform)..It's quite
possible that all the JUMP code is clean, however. In any case, this
will only be an issue if
I guess the memory issue might be moot for DataStore-based datasets
anyway, since the whole point is to only keep in memory what is
currently displayed on the screen.
But simpler is always better! Alarm bells start ringing for me when I
see counts being used - the semantics seems like they
I think the other developers need to understand that the cost of supporting
per-feature modified status will be a per-feature cost of (size of int) *
number of attributes. I'm not sure I made that clear. Currently the memory
cost is for all features on all layers. Perhaps there is needed a way
Larry Becker a écrit :
I think the other developers need to understand that the cost of
supporting per-feature modified status will be a per-feature cost of
(size of int) * number of attributes. I'm not sure I made that
clear. Currently the memory cost is for all features on all layers.
Perhaps you could extend BasicFeature to be a MutableBasicFeature, and
this is the concrete class that would be used by Writeable DataStores.
Only MutableBasicFeature would incur the overhead of tracking changes.
Whether the DataStore is writeable could be determined dynamically as
well (ie
Of course the most famous attribute memory-saving scheme is Michael's
permgen attribute string scheme for dbf files. That one saves a ton
of memory on typically redundant data, until you run out of permgen
memory.
Note that I changed the mechanism which now use normal memory through a
Michael,
Allowing for disconnected editing is an interesting extension, for
sure. I don't see the fact that the modification state is internal is a
major problem. After all, if they were exposed as regular attributes you
would still need custom code to determine that these were actually state
mhm.. although I must admit that I understand only half of what you all
write - I like the idea of MutableBasicFeature (BMF).
However, this would also require to check which (analysis and editing)
tools use BasicFeature by now - so that a MBF would be created again. On
the other hand, if they
Good point about the problem with MBF not being created by external code
- as well as the fact that since they are known to be new they don't
need the information contained in MBFs.
Which makes me think that maybe an even better approach is to treat
Features themselves as immutable. Any
Larry,
I'm working right now to get my own build of the OpenJUMP core running
again. When this is done I will test out your new BasicFeature class
and plug-in and will let you know how things work.
Landon
On Tue, Apr 7, 2009 at 8:26 PM, Stefan Steiniger sst...@geo.uzh.ch wrote:
Hei Larry,
SS,
Attached is my plugin for SkyJUMP to test the BasicFeature isModified()
code.
regards,
Larry
On Thu, Apr 2, 2009 at 2:34 PM, Sunburned Surveyor
sunburned.surve...@gmail.com wrote:
Larry: I'll squeeze in the code for a Select All Modified Features
Tool as soon as I get the chance.
Hei Larry,
thank you for taking the initiative (I still haven't read the emails on
that topic - sorry)
stefan
Larry Becker schrieb:
SS,
Attached is my plugin for SkyJUMP to test the BasicFeature
isModified() code.
regards,
Larry
On Thu, Apr 2, 2009 at 2:34 PM, Sunburned Surveyor
Paolo Rizzi wrote:
Hi,
We play with WFS-T at work, where the mechanism of what really happens
finally is hidden behind datastore drivers of WFS server like Geoserver or
others. Anyhow, the problem is still the same than with direct connections
to database. For example this document is
to
solve them.
Bye
Paolo Rizzi
-Alkuperäinen viesti-
Lähettäjä: Larry Becker [mailto:becker.la...@gmail.com]
Lähetetty: to 2.4.2009 22:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track modifications
Paolo,
You make some good points
problems, even if now it's not the time to
solve them.
Bye
Paolo Rizzi
-Alkuperäinen viesti-
Lähettäjä: Larry Becker [mailto:becker.la...@gmail.com]
Lähetetty: to 2.4.2009 22:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track
viesti-
Lähettäjä: Larry Becker [mailto:becker.la...@gmail.com
mailto:becker.la...@gmail.com]
Lähetetty: to 2.4.2009 22:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track modifications
Paolo
mailto:becker.la...@gmail.com]
Lähetetty: to 2.4.2009 22:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track
modifications
Paolo,
You make some good points. I wasn't really trying to solve all
database
Hi,
We play with WFS-T at work, where the mechanism of what really happens finally
is hidden behind datastore drivers of WFS server like Geoserver or others.
Anyhow, the problem is still the same than with direct connections to database.
For example this document is handling rather similar
[mailto:becker.la...@gmail.com
mailto:becker.la...@gmail.com
mailto:becker.la...@gmail.com mailto:becker.la...@gmail.com]
Lähetetty: to 2.4.2009 22:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track
Hi,
We play with WFS-T at work, where the mechanism of what really happens
finally is hidden behind datastore drivers of WFS server like Geoserver or
others. Anyhow, the problem is still the same than with direct connections
to database. For example this document is handling rather
Hi,
I wonder how it has been done in a new WFS plugin that can do transactions.
The transaction icon gets highlighted only if something has been modified, so I
think there must be some chance tracking system. And I don't believe really
that anybody makes a WFS-T client that sends the whole
Rahkonen Jukka wrote:
Hi,
I wonder how it has been done in a new WFS plugin that can do transactions.
The transaction icon gets highlighted only if something has been modified, so
I think there must be some chance tracking system. And I don't believe really
that anybody makes a WFS-T client
Hi SS,
You missed the point. After loading the layer, with a simple boolean it
would always be set to true.
Larry
On Wed, Apr 1, 2009 at 5:34 PM, Sunburned Surveyor
sunburned.surve...@gmail.com wrote:
Larry,
I like your solution to this problem, but I wonder if it is necessary
to track
Larry wrote: You missed the point. After loading the layer, with a
simple boolean it would always be set to true.
This must be due to the attributes being set once when the feature is
created from the data source when a layer is loaded. I see now that
your code accounts for this.
It is
I think the WFS code is probably just a case of having to implement Feature
modification detection at a higher level, since there was no low level
support for it. Modifications to BasicFeature (not AbstractFeatureClass
BTW) would not require a listener to detect changes. Therefor Feature
Larry Becker wrote:
Hi,
I think the WFS code is probably just a case of having to implement Feature
modification detection at a higher level, since there was no low level
support for it. Modifications to BasicFeature (not AbstractFeatureClass
yes, I agree (although it was actually Ugo who
So I think we have come to an agreement then. :]
Larry: Do you want to try some modifications to the BasicFeature
class? If not, I can try to do it today or tomorrow.
SS
On Thu, Apr 2, 2009 at 8:27 AM, Andreas Schmitz schm...@lat-lon.de wrote:
Larry Becker wrote:
Hi,
I think the WFS code
Andreas is right, for this to work for each modified Feature it must
be known if it was modified, inserted or deleted.
Also there's the case of conflict resolving.
If user A reads a Feature from a DB, modify it and then write it back
to the same DB, there's the possibility that in the meantime
SS,
The full mod to BasicFeature is attached. Why don't you go ahead with your
idea of testing it out with a Select all modified Features tool?
regards,
Larry
On Thu, Apr 2, 2009 at 10:44 AM, Sunburned Surveyor
sunburned.surve...@gmail.com wrote:
So I think we have come to an agreement
Paolo,
You make some good points. I wasn't really trying to solve all database
update problems, but here is a try.
Assumption: The database PK is stored in an attribute. In this case
Features that show modified already have a PK so all is well. When new
Features are created, the PK will be
Becker [mailto:becker.la...@gmail.com]
Lähetetty: to 2.4.2009 22:33
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track modifications
Paolo,
You make some good points. I wasn't really trying to solve all database
update problems, but here is a try
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] Modifying BasicFeature to track modifications
Paolo,
You make some good points. I wasn't really trying to solve all database
update problems, but here is a try.
Assumption: The database PK is stored in an attribute
Larry,
I like your solution to this problem, but I wonder if it is necessary
to track the modifications to all of the attributes. As soon as a
single attribute value has been modified, you could flag the whole
feature as in need of an update.
In this case our code might look like this:
//
59 matches
Mail list logo
