[fdo-users] Question on associations between classes

[Maksim Sestic]

Current status :-) on Parcel Annotations:

Class definition (not FeatureClass) doesn't have a Geometry property, so I
resorted to creating pair of X,Y double value data properties. They are used
in AutoCAD only anyways, MapGuide has it's own way of displaying them so
it's not a problem for me.

Now for one little quirk:

ObjectPropertyDefinition assumes that both Collections and
OrderedCollections may contain Classes with mandatory IdentityProperties,
which is bit strange. I understand requiring IdentityProperty on
OrderedCollection (it's order is based on identity of it's elements, I
assume), but simple Collections, in my view, do not need IdentityProperties
since they're simply collection of objects in whatever order I created them. 

This introduces one more drawback - I had to create an IdentityProperty for
my Annotation class, making it concrete in that way. I just want it's
meta-data definition within FeatureSchema and nothing more - actual
instances of Annotation will get added to the Parcel.Annotations collection.
Now I'm confused :-) since I have no idea of how to create contained-only
class definition to include it's meta-data only, and use it as instantiated
collection element at the same time.

Anyone, please help :-)

P.S.
Autodesk Map 3D 2007 (SP3) went berserk when I introduced object property to
a feature class. It's DataGrid ceased working (error reported: "Unhandled
exception at 0x7c812a5b in acad.exe: Microsoft C++ exception: IGWSException
at memory location 0x0b2cfea0"... But this is a lesser problem.

With kindest regards,
Maksim Sestic



Maksim Sestic wrote:
> 
> I was thinking of using following FDO approach, please correct me if I'm
> wrong at some point:
> 
> 1) Annotations
> 1.1) Create Annotation Class (not FeatureClass) since Classes are globally
> accessible throughout DataStore.
> 1.2) Annotation class, among other properties, posesses one geometric
> property (it's insertion point). It does not posses identity property
> since it's always used as a child of a FeatureClass.
> 1.3) Create FeatureClass named "Parcel". It posesses identity, data and
> geometric properties. As an extra, it also posseses an Object property - a
> collection of Annotation objects - meaning that one Parcel may posses zero
> or more Annotations.
> 
> 2) Projects
> 2.1) Create globally accessible Project Class (not FeatureClass).
> 2.2) Project class posesses identity and data properties.
> 2.3) Create FeatureClass named "Parcel". It posesses identity, data and
> geometric properties. As an extra, it also posesses an Association
> property.
> 2.4) An instantiated Project object gets associated to Parcel feature
> class in the following manner:
> 2.4.1) FdoAssociationPropertyDefinition::SetAssociatedClass refers to
> existing Project class instance.
> 2.4.2) FdoAssociationPropertyDefinition::SetMultiplicity is set to "1"
> (given Project instance may hold only one Parcel instance).
> 2.4.3) FdoAssociationPropertyDefinition::SetReverseMultiplicity to "0" (a
> Project may or may not have Parcels when instantiated).
> 2.4.4) SetReverseName to "Parcel"
> 2.4.5) Set Delete rule to Break (I don't want to have my Parcel deleted if
> someone deletes Project containing it, since some other Project might also
> refer to the same Parcel. I also don't want my Project instance affected
> if someone deletes this particular Parcel either).
> 2.4.6) Rinse and repeat 2.4.1) to 2.4.5) for each Project this Parcel
> belongs to.
> 
> Now, for the tricky part - one Parcel may get associated to more than one
> Project. Is it possible to add more than one
> FdoAssociationPropertyDefinition to a FeatureClass?
> 
> Someone might ask why don't I associate features to the projects (other
> way round), meaning that Project class has association property
> associating zero or more feature classes. The answer is simple - anytime
> schema changes and new feature class gets added to it - I would have to
> change Project's associtaion definition to include newly added feature
> class. Or am I wrong? :-)
> 
> Regards,
> Maksim Sestic
> 
> 
> 
> Maksim Sestic wrote:
>> 
>> Dear all,
>> 
>> I need to decide on what approach to take regarding logically associated
>> classes described by schema:
>> 
>> 1) My features have annotations
>> Each instance of my FeatureClass may have 0..n annotations. Describing
>> them is a lesser problem, the general question is - how do I store
>> annotations and how do I relate physical class to them? I was thinking to
>> resort to standard RDBMS approach - creating Annotations feature class
>> (table) with rows (annotation instances) pointing to it's owner (physical
>> class). Maybe there's more "proper" approach, as shortly described in FDO
>> DevGuide, using other types of Classes than the FeatureClass?
>> 
>> 2) My features belong to projects
>> Each instance of my FeatureClass may belong to 0...n projects. Meaning -
>> one feature may belong to two (or more) different projects at the same
>> time. Naturally, there's only one instance of a feature class in a
>> datastore. Using classical RDBMS approach, I would create Projects table
>> with records describing actual projects, accompanied by related table to
>> keep pointers on features belonging to that project. What FDO has to say
>> about this type of association?
>> 
>> With kindest regards,
>> Maksim Sestic
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Question-on-associations-between-classes-tf4073626s18162.html#a11595320
Sent from the fdo-users mailing list archive at Nabble.com.