[fdo-users] RE: Question on associations between classes

[Maksim Sestic]

Hi Orest,

I already found out painful truth about Map and MG not supporting
ObjectProperties :-) Huh, not only they're not supporting ObjectProperties,
they both rather crash or report errors than skipping them. To some extent -
both MG and Map recognize them, but fail to either display or execute any
queries on FeatureClasses containing ObjectProperties.

Anyways, I decided not to go for ObjectProperties, rather organize present
contained classes (e.g. "Annotation") as stand-alone, non-Feature ones and
associate them to their parents via AssociationProperties. I hope that
AssociationProperties will not crash neither MG nor Map :-) Did you
experience any incosistencies on that matter (Map 2007, Map 2008, MG 2007,
MG 2008)?

* * *

Regarding Collections - as far as I understand the model, providers
(supporting them) should actually deal with internal indexing of Collection
members themselves. OrderedCollection is different animal since it uses
underlying identifier to sort it's members. In fact, Collections should even
ignore underlying identifier(s) - providers implementing them are supposed
to keep track of present indicies and assign new ones as soon as user adds
an object into the Collection, or deletes existing one. Kind of simple array
of objects if you know what I mean. Users, in fact unaware of internal
indicies, should use collection enumerator to access it's members in
whatever order they were thrown in.

 
With kindest regards,
Maksim Sestic 



Orest Halustchak wrote:
> 
> Hi Maksim,
> 
> You should be aware than currently neither MapGuide nor Map handle FDO
> associations or object properties. Map should have skipped the object
> properties rather than getting unhandled exceptions in the data table,
> but either case is not going to help you.
> 
> The issue with requiring an identify for object property collections is
> to be able to identify each item in the collection. It would only need
> to be a local identifier within the parent's collection. It would be
> used for update and delete processing as a way to identify an item
> uniquely.
> 
> You had a question about multiple associations for parcels and projects.
> This sounds like a many:many case? You could do that by having an
> intermediate class that has 1:many associations to both parcels and
> projects. However, Map and MG wouldn't be able to use this
> automatically.
> 
> Orest.
> 
> -----Original Message-----
> From: fdo-users-bounces at lists.osgeo.org
> [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
> Sent: Saturday, July 14, 2007 12:36 PM
> To: fdo-users at lists.osgeo.org
> Subject: Re: [fdo-users] Question on associations between classes
> 
> 
> 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-tf4073626
> s18162.html#a11595320
> Sent from the fdo-users mailing list archive at Nabble.com.
> 
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> 
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> 
> 

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