Hi Michael, good thoughts.
Yes, I'm in process of implementing some datastore plugins that will
permit the dynamic reading and writing to a database. I wrote a quick
hacky plugin many years ago that does this for PostGIS. I want to
release this to the community because it seems quite useful, but I'm
first tackling a complete code rewrite with a nice UI. I'm currently
using a Primary or Unique key to synchronize a database table and OJ's
FeatureCollection. If a feature gets modified, I use the key to update
the appropriate record in the database. Obviously, mayhem ensues if a
user were to modify a feature and it's primary key attribute ... they'd
be modifying the wrong record in the database.
So, yes, I'm trying to prevent the modification of certain attributes.
Preventing attribute writing through the LayerTable seemed like the
easiest approach, but I'm definitely open to ideas on how we can make
this rock solid. I hadn't considered adding a check to
BasicFeature.setAttribute, but it does sound prudent.
I'm not sure I understand your last comment, can you please elaborate?
If the readonly attribute is not cloned, then a deep copy of a
FeatureSchema object wouldn't have the same constraints as the original, no?
-- Kevin
On 9/3/2010 2:25 PM, Michaël Michaud wrote:
Hi,
I just had a look at your patch which seems good to me.
I have some questions about it :
1 - Do you plan to improve database connection plugins to prevent
modifications on some kinds of database attributes ?
2 - Do you just want to prevent attribute writing throught the LayerTable ?
Because if you want a stronger protection (preventing attribute writing
from attribute edition plugins, new plugins, scripts) , I think some
methods have to be added in the feature implementation
(AbstractBasicFeature.setAttribute ? BasicFeature.setAttribute ?) to
check if setting a new attribute value is authorized by the feature
schema. I'm not sure about setAttributes which is a low level method.
What do you think ? Checking before each setAttribute may slowdown the
whole process.
And if we go this way, I wonder if cloning attributeReadOnly property
with the FeatureSchema is necessary.
What do you think ?
Michaël
Le 02/09/2010 17:59, Kevin Neufeld a écrit :
Patch has been committed at r2034, no problems. Let me know if anyone
has issues with the addition.
Thanx all,
-- Kevin
On 9/2/2010 8:29 AM, Sunburned Surveyor wrote:
Kevin,
You've been added to the Jump Pilot Project on Sourceforge and now
have write access to the SVN. You can commit your patch so we get the
changes in our nightly build.
If you have trouble with the commit, please let me know.
The Sunburned Surveyor
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
