Martin wrote: "They certainly follow the relational paradigm pretty closely, which will make Landon happy 8^) Me too, actually - I don't have anything against the relational paradigm, and it's certainly a lot more battle-hardened than the object DBMS world."
It's not that I am a fan of the realtional model. I'm often frustrated at the limitations of it when I am designing relational databases. If I have my choice when building a data tracking system from scratch I'd rather use objects and a Java program than a relational database. However, I find in my work with OpenJUMP that it is often easier to associate a new property or function with an existing class than it is to add it. Maybe if I wasn't working on a huge hunk of legacy code with a bunch of public interfaces that have already been exposed to plug-in developers this would be different. SS On 6/12/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > I've been thinking about this, and now I am really confused! > > I think I can summarize my confusion by saying this: > > I don't think we will need to introduce a uniquely identified > FeatureSchema and/or a FeatureType if we introduce a restriction for > unique Layers. (Or at least a way to associate a unique identifier > with Layers.) I can associate any type or constraint or restriction on > a uniquely identified Layer as easily as I can a uniquely identified > FeatureSchema. > > After thinking about it I believe that it is better to work with Layer > objects than it is FeatureSchema objects. This is because we don't > expose FeatureCollections or FeatureSchemas to the user at this point. > We expose Layers. A user won't want to apply a attribute value range > or other constraint to a FeatureSchema, they'll want to apply it to a > Layer. If I'm a user that doesn't subscribe to this list I don't even > know that FeatueSchemas and FeatureCollections exist. I say we keep it > that way. > > The only downfall that I can think of to this system is that If a > programmer is interested in using OpenJUMP's feature model as a > library in an external program, but doesn't want to use Layers they > won't have the control we are talking about. > > Maybe Paul has some reasons why this won't work in his situation. > > The Sunburned Surveyor > > On 6/12/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > FeatureType seems like a good name for this. > > > > It does seem like this could be added without too much risk right now, > > with very little semantics or functionality around it (other than what > > Paul is presumably building). > > > > I guess if there's a real need for this functionality it will become > > obvious as people ask for more functionality exposed for it. > > > > I'm just a bit worried that this whole area in general has no very clear > > model to follow. Every system seems to do something a bit different. > > If there's no initial overall vision of where this is going, we risk > > building off in directions which are very hard to corral back later. It > > would be nice to pick an existing model and follow or extend it. Maybe > > the Geodatabase model is a good one to look at. They certainly follow > > the relational paradigm pretty closely, which will make Landon happy > > 8^) Me too, actually - I don't have anything against the relational > > paradigm, and it's certainly a lot more battle-hardened than the object > > DBMS world. > > > > Sunburned Surveyor wrote: > > > I must weigh in with Paul on this one guys. I see a lot of potential > > > uses for uniquely identifying FeatureSchemas. I guess that I would > > > call this a FeatureType. If you are curious about the applications of > > > defining and uniquely identifying FeatureTypes just take a look at the > > > ESRI Geodatabase. (For example, FeatureTypes would allow you to > > > specify a range of allowed values for an attribute.) I believe in ESRI > > > FeatureTypes are called FeatureClasses. > > > > > > I also don't think that it is unreasonable to specify that an OpenJUMP > > > project contain no duplicate FeatureTypes. However, I do see that we > > > allow Layers to have the same name, which I think is a bad thing... I > > > guess that I never noticed this before. > > > > > > Martin wrote: "This all seems like a lot of extra complexity to > > > support something that at the moment is really only your own use case. > > > Perhaps you should > > > publish this as a plugin for now, and if it gets used a lot then the > > > JUMP project can think about incorporating it in the core." > > > > > > I would agree with Martin on this point. I don't think it would be to > > > difficult to encapsulate a system for uniquely identifying > > > FeatureSchema's in a plug-in. You'd could automatically add the Layer > > > name (as the unique ID for the FeatureSchema) and a reference to the > > > FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If > > > the user tried to create a Layer with a duplicate name you could > > > create an error message. > > > > > > Or you could prompt the user to enter a name for a FeatureSchema when > > > creating a layer, although this might be more confusing for them. > > > > > > I think the best solution would be to allow users to assign a unique > > > FeatureType or FeatureSchema to the Layers that they select (after the > > > Layers had been created, of course). That way we aren't forcing this > > > on users that have no need for it. > > > > > > You could capture the relationship between the FeatureSchema, Layer, > > > and unique FeatureSchema indentification at the time that the user > > > made the association. If you want it to be really easy you could > > > automatically fill the unique id text box with the name of the Layer > > > that the user selected for the association. That would solve your > > > reflection problem. You would never need to ask a FeatureSchema if it > > > had a unique name. You could just see if there was a unique id > > > associated with the instance of FeatureSchema by asking the plug-in. > > > > > > If Paul think's he would be interested in doing something with > > > FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd > > > be interested in the design, as I think this really is something that > > > I will want to tap into in the future. > > > > > > The Sunburned Surveyor > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > _______________________________________________ > > > Jump-pilot-devel mailing list > > > 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 > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
