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
To jump in here, the DataStore API was developed specifically to provide
live connections to DBs. The DataSource API was old code that was just
our first quick attempt at abstracting the concept of connecting to data
sources. It was basically obsoleted by the DataStore work.
We also found th
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
well..
it is wise - I aggree. But I would not promise anything, since
a) JTin does something new and deegree requires I believe certain
stability and testing, and
b) we need to check how much the things are separable from OpenJUMP
structures.
So.. the first steps are
a) to see how/if we can sep
I'll do whatever I need to. Do you have an address for degree's code repository
so I can check out a tree.
--Christopher
--- On Thu, 4/23/09, Sunburned Surveyor wrote:
> From: Sunburned Surveyor
> Subject: [JPP-Devel] Making JTin Part of the deegree Project
> To: "OpenJump develop and use"
I've been talking briefly with the deegree Project programmers about
making JTin an official part of their library. I think this would be
wise, since deegree is an OSGeo project and the work is being done
under the OSGeo Summer-of-Code umbrella.
I am willing to work with Christopher and JTin on ge
Hi Paolo,
Thanks for your thoughts. I'll defer to your experience in implementing
database plugins since I wasn't directly involved with coding the ArcSDE
plugin. The problem I have with the DataStore ArcSDE driver is that it is
inherently multithreaded when you have more than one layer, so it
> Thanks Stefan. Also, as far as the best database base class to
> consider, we have DataSource which loads the layer into memory, and
> DataStore which doesn't but is read-only, and IMHO has problems with
> multiple layers due to threading. I guess, if I was starting the task
> of implementi
Hi,
Here is the explanantion of the bug discussed in user's list
This is a regression issued from a modification I did one month ago. I
explain it for those interested.
I set every newly created layer to featureCollectionModified=true
The motivation was to warn the user that some layers are unsa
19 matches
Mail list logo
