Hi Kevin, > 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. I see more clearly your intention now. Great addition ! And thanks to plan to release this work to the community. > 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? Not sure it makes sense. My first thought was that readonly attribute was readonly in the context of a datastore (identifier or key), but may loose this property in the context of a new local layer created by cloning the schema. But this is probably not a big issue. I now think readOnly property can be cloned as any other. There is probably no major drawback.
Michaël > -- 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 > > ------------------------------------------------------------------------------ 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
