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 th
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 wrote:
> > An example of the standard usage pattern for JDBC can be seen in:
> 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 o
> 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 s
--- On Thu, 4/30/09, Sunburned Surveyor wrote:
> From: Sunburned Surveyor
> Subject: Re: [JPP-Devel] Modifying BasicFeature to track modifications
> To: "OpenJump develop and use"
> Date: Thursday, April 30, 2009, 7:30 AM
> Larry wrote: "I appreciate all o
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
devel
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 w
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 att
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 wrote:
> >From the point of view of BasicF
>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) {
setA
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 call
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 n
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 purposes,
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)
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
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 w
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'
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 wrote:
> What can I say that I haven't already said? If you have the code I sent
> you, I wou
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
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()
{
// Do
>
> 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 likel
>
> 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 B
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 dat
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 disposa
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 change
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 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
> 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
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 b
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
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 t
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 mus
I agree that a mechanism to reset the modified status is needed, especially
after the changes to the layer have been flushed to the database. I'll add
this to BasicFeature.
Your comment about carrying around state data after it is needed is
reasonable. The code could check for modified on-the-fl
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 th
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 mu
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 th
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 wrote:
> Hei Larry,
>
> thank you for tak
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
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.
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 docum
> 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 rathe
eady committed a ROAD on the very same terrain.
> > This is not a conflict in strict DB parliance, but it's
> nonetheless a
> > real conflict in spatial terms.
> > It woould be great to have a GIS capable of detecting and
> presenting to
>
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 si
a conflict in strict DB parliance, but it's nonetheless a
> > real conflict in spatial terms.
> > It woould be great to have a GIS capable of detecting and presenting
> to
> > the user such conflicts, to be resolved, or at least signalled.
> >
> > I hope thi
ounded like a rant, it is not by any mean!!! :-)
> Just trying to summarize all problems, even if now it's not the time to
> solve them.
>
> Bye
> Paolo Rizzi
>
> >
> >
> > -Alkuperäinen viesti-
> > Lähettäj
unded like a rant, it is not by any mean!!! :-)
> Just trying to summarize all 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...@gma
to be resolved, or at least signalled.
I hope this didn't sounded like a rant, it is not by any mean!!! :-)
Just trying to summarize all problems, even if now it's not the time to
solve them.
Bye
Paolo Rizzi
>
>
> -----Alkuperäinen viesti-
> Lähettäjä: Larry Bec
t; 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. I wasn't really trying to sol
---
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. I wasn't really trying to solve all database
update pr
Larry: I'll squeeze in the code for a "Select All Modified Features
Tool" as soon as I get the chance.
Paolo: You post was a great summary of the challenges of implementing
true read/write support of features to a database in OpenJUMP. I think
it demonstrates why monitoring for this purpose needs
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
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
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 meanti
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 wrote:
> Larry Becker wrote:
>
> Hi,
>
>> I think the WFS code is probably ju
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
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
modifica
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 interes
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
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 clie
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 lay
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:
// Declar
61 matches
Mail list logo
