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 int[] array so that the 
first time a setAttribute() or setAttributes() method is called, if the 
beginInit() method has been called before it means that it's 
initialization time. If it has not been called but the int[] array has 
not been created, it's initialization time anyway, so it can create the 
int[] array and dispose of it as soon as all attributes have been set at 
least once.
This way both mod-aware and non-mod-aware code would work.

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.

I feel that the mod mechanism should require awareness by the client 
code in any case, since you have to write dirty Features out sooner or 
later, so it may not be the case to put too much burden on the Feature 
shoulders...

Also, apart from modified Features, there're inserted and deleted one, 
that should be managed. So the Feature itself may not even be aware at 
all of it's own dirtyness. I see this information to pertain to Feature 
containers more than to Features themselves...

Bye
Paolo


> 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-fly while it is 
> incrementing the attribute mod count and if it is greater than one, set 
> a boolean instead and dispose of the array of ints.  You would lose the 
> ability to determine individual attribute mods (not sure if it is 
> needed), however you would only save memory in modified records which 
> wouldn't usually be very much.
> 
> I was hoping someone would come up with a clever hack that wouldn't 
> require the int array.  All of the optimizations that I have considered 
> break in one case or another.
> 
> BTW, if you really want to save memory on attribute storage, I have a 
> number of questionable schemes that load attributes on an as-needed 
> basis.  :-)  SkyJUMP even has an optimization were layers that aren't 
> visible are not loaded into memory until you make them visible, although 
> it doesn't go as far as removing them when you make them invisible.  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.
> 
> Larry
> 
> On Thu, Apr 23, 2009 at 4:06 PM, Martin Davis <mbda...@refractions.net 
> <mailto:mbda...@refractions.net>> wrote:
> 
>     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 that particular function is used.
> 
>     re tracking modifications - how about providing a method that lets you
>     clear the modified flag?  Then the feature can be constructed as
>     necessary and then marked as clean.
> 
>     It seems heavyweight to carry around a set of data which is only really
>     of use during the construction phase of a Feature.  To avoid this, I'd
>     even suggest constructing a Feature as needed, then creating a new
>     Feature from it via a constructor which sets the modified flag
>     appropriately.  Anything to avoid requiring more storage.
> 
>     How does GeoTools handle this?
> 
>     Larry Becker wrote:
>      > 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 multiple
>      > times with different attribute indexes, so it is necessary to track
>      > the changes to each one separately.
>      >
>      > Mutating Geometries in place is a concern.  I have never seen code
>      > that does this, and certainly none of the edit tools or any plugins
>      > that use transactions do this, but it may be possible.  Could you
>     just
>      > modify the Coordinate.x and y values?  I'll try to construct a
>      > Beanshell test for this, but I doubt that this is a serious concern.
>      > All of the tools and plugins that I have tried so far play by the
>     rules.
>      >
>      > Larry
>      >
>      > On Thu, Apr 23, 2009 at 2:12 PM, Martin Davis
>     <mbda...@refractions.net <mailto:mbda...@refractions.net>
>      > <mailto:mbda...@refractions.net
>     <mailto:mbda...@refractions.net>>> wrote:
>      >
>      >     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 other thread, before the problem of
>     partial
>      >     > database updates can be solved, we must first be able to
>      >     determine if
>      >     > a Feature has been modified.  This is not currently possible in
>      >     all of
>      >     > the JUMP variants that I am familiar with, although Kosmo
>     may have
>      >     > implemented it.
>      >     >
>      >     > The simplest way of implementing it that I can see is to modify
>      >     > BasicFeature to include:
>      >     >
>      >     > private int[] attributeModCount;  //this is a parallel array to
>      >     > Object[] attributes
>      >     >
>      >     > Then it would be necessary to allocate the
>     attributeModCount array
>      >     > when setAttributes(Object[] attributes) is called.
>      >     >
>      >     > In addition each time setAttribute(int attributeIndex, Object
>      >     > newAttribute) is called, add the line of code:
>      >     >
>      >     > attributeModCount[attributeIndex]++
>      >     >
>      >     > With these modifications we could then define:
>      >     >
>      >     > public boolean isFeatureModified() {
>      >     >     for (int i=0; i<attributeModCount.length; i++) {
>      >     >       if (attributeModCount[i] > 1)  //modified is defined as
>      >     setting
>      >     > an attribute more than once
>      >     >          return true;
>      >     >     }
>      >     > return false;
>      >     > }
>      >     >
>      >     > Would this work and does this seem like something we should
>      >     consider?
>      >     >
>      >     > regards,
>      >     > Larry
>      >     > --
>      >     > http://amusingprogrammer.blogspot.com/
>      >     >
>      >    
>     ------------------------------------------------------------------------
>      >     >
>      >     >
>      >    
>     
> ------------------------------------------------------------------------------
>      >     >
>      >     >
>      >    
>     ------------------------------------------------------------------------
>      >     >
>      >     > _______________________________________________
>      >     > Jump-pilot-devel mailing list
>      >     > Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>
>      >     <mailto:Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>>
>      >     > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>      >     >
>      >
>      >     --
>      >     Martin Davis
>      >     Senior Technical Architect
>      >     Refractions Research, Inc.
>      >     (250) 383-3022
>      >
>      >
>      >    
>     
> ------------------------------------------------------------------------------
>      >     Crystal Reports &#45; New Free Runtime and 30 Day Trial
>      >     Check out the new simplified licensign option that enables
>     unlimited
>      >     royalty&#45;free distribution of the report engine for externally
>      >     facing
>      >     server and web deployment.
>      >     http://p.sf.net/sfu/businessobjects
>      >     _______________________________________________
>      >     Jump-pilot-devel mailing list
>      >     Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>
>      >     <mailto:Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>>
>      >     https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>      >
>      >
>      >
>      >
>      > --
>      > http://amusingprogrammer.blogspot.com/
>      >
>     ------------------------------------------------------------------------
>      >
>      >
>     
> ------------------------------------------------------------------------------
>      > Crystal Reports &#45; New Free Runtime and 30 Day Trial
>      > Check out the new simplified licensign option that enables unlimited
>      > royalty&#45;free distribution of the report engine for externally
>     facing
>      > server and web deployment.
>      > http://p.sf.net/sfu/businessobjects
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Jump-pilot-devel mailing list
>      > Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>
>      > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>      >
> 
>     --
>     Martin Davis
>     Senior Technical Architect
>     Refractions Research, Inc.
>     (250) 383-3022
> 
> 
>     
> ------------------------------------------------------------------------------
>     Crystal Reports &#45; New Free Runtime and 30 Day Trial
>     Check out the new simplified licensign option that enables unlimited
>     royalty&#45;free distribution of the report engine for externally facing
>     server and web deployment.
>     http://p.sf.net/sfu/businessobjects
>     _______________________________________________
>     Jump-pilot-devel mailing list
>     Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
> 
> 
> 
> -- 
> http://amusingprogrammer.blogspot.com/
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty&#45;free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


------------------------------------------------------------------------------
Crystal Reports &#45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty&#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to