<div>i'm not complaining, (maybe some good programming techniques will rub off), but is this an fdo-users thread or an fdo-internals? It is quite a bit over my head.</div>
<div>:)<br><br></div>
<div class="gmail_quote">On Mon, Jul 26, 2010 at 7:30 AM, Orest Halustchak <span dir="ltr"><<a href="mailto:orest.halustchak@autodesk.com">orest.halustchak@autodesk.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi,<br><br>One of the things available with associations is the definition and handling of cardinality rules and cascade delete rules. With object properties, the objects are contained within the parent object and automatically would be deleted when the parent is deleted. It provides not just the advertising of where there are associations and object properties, but some management of them as well.<br>
<br>Crispin, yes, these allow the handling of association rules and complex objects that contain ADT style properties to be managed by the provider / server. You said 'These can, of course, be modelled at the application level but rich object management is just a "better" way of handling the real-world.' It's a question that comes up for the more advanced capabilities and data types that may only be implemented by a smaller number of FDO providers. If a user wanted to take advantage of those capabilities, then they would be restricted to the providers that support them. The other argument is that if advanced capabilities can be implemented above the FDO level, then possibly they could be available with more providers since the providers don't have to be upgraded to handle all the new capabilities (and there are quite a few providers available now, open source and commercial, and growing). Personally, I feel that there are cases where something cannot be done easily or with enough performance above FDO where you can argue that it should be at the FDO level. But, should we also be looking at the alternative where it may make sense? There is obviously a trade off of where data integrity rules are known versus more wide-spread use of the capability. Open question. Note that there was some roughly related discussion a while ago as part of a "futures discussion": <a href="http://trac.osgeo.org/fdo/wiki/FdoClientUtilities" target="_blank">http://trac.osgeo.org/fdo/wiki/FdoClientUtilities</a><br>
<br><br>Thanks,<br>Orest.<br><br><br>-----Original Message-----<br>From: <a href="mailto:fdo-users-bounces@lists.osgeo.org">fdo-users-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:fdo-users-bounces@lists.osgeo.org">fdo-users-bounces@lists.osgeo.org</a>] On Behalf Of Brent Robinson<br>
Sent: Friday, July 23, 2010 1:30 PM<br>To: FDO Users Mail List<br>Subject: RE: [fdo-users] RE: Object and Association Support<br><br>Associated geometry is an interesting case. I tried a select, with filter similar to:<br>
<br> ParentClass.ChildAssociation.Geom EnvelopeIntersects<br> GeomFromText('<geometry text>')<br><br>with the OSGeo.MySQL and OSGeo.PostgreSQL providers but it didn't work. The scoping got removed and it tried to filter on ParentClass.Geom. However, a filter on a data property such as:<br>
<br> "ParentClass.ChildObject.Value = 1"<br><br>works fine. I don't know of any technical reason why the filter on associated geometry would not work; it would probably be just a matter of bug fixing to get these providers to support it.<br>
<br>In the case of 1:m associations, the "ParentClass.ChildObject.Value = 1" would select all ParentClass features with at least one associated ChildObject with Value=1. However, when I tried this with the MySQL provider, if a feature had 2 ChildObjects that passed the filter, then the feature got selected twice.<br>
<br>Since associations have been under-utilized sofar, there are probably a few bugs like the above-mentioned ones, that would need to be fixed before association properties would be working smoothly.<br><br><br>-----Original Message-----<br>
From: <a href="mailto:fdo-users-bounces@lists.osgeo.org">fdo-users-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:fdo-users-bounces@lists.osgeo.org">fdo-users-bounces@lists.osgeo.org</a>] On Behalf Of Crispin_at_1Spatial<br>
Sent: Friday, July 23, 2010 3:46 AM<br>To: <a href="mailto:fdo-users@lists.osgeo.org">fdo-users@lists.osgeo.org</a><br>Subject: [fdo-users] RE: Object and Association Support<br><br><br>Orest,<br><br><br>Orest Halustchak wrote:<br>
><br>> Crispin, do you have some examples of the types of data models that you<br>> would like to support?<br>><br><br>This very simple example is for the management of cartographic labelling for<br>an object - is positioned text. I am sure this is something that has been<br>
asked of some of the high-end editing clients using FDO.<br><br>Take a river class - some rivers are short and have no labels (these<br>requirements are for positioned 'cartographic' labels, not auto-generated<br>
labels). Some have one and some have many. The labels do not exist as a<br>"layer" themselves as are only ever associated with the river - when the<br>river is off they disappear without needing to have application-level logic<br>
such as a layer-group fudge. Editing the label geometry is really editing<br>one of the complex geometry/attribute the river object.<br><br>More complex examples such as property boundaries containing properties and<br>masts where the properties and masts are entities of their own and also<br>
shared with other objects. These can, of course, be modelled at the<br>application level but rich object management is just a "better" way of<br>handling the real-world.<br>Just as managing topographic detail is moving from classic lines<br>
(historically print/plot/carto driven needs) to polygons (GI<br>representation)... business modelling is moving to multi-cardinality<br>representation rather than simple features.<br><br>Another Question:<br>If an object in a class has a geometry and the association/object properties<br>
include geometry, what will happen with a spatial query? By default I<br>assume that only the parent geometry be used in the query as the filter must<br>explicitly define the geom column that it is acting on.<br>Brent said above that you could do a filter like<br>
"ParentClass.ChildObject.Value = 1" so I assume this is supported for<br>spatial filters. Where there is 1:m cardinality on associations does the<br>query below automatically run on *every* association - that would be very<br>
good!!!<br> ParentClass.ChildAssociation.Geom EnvelopeIntersects<br>GeomFromText('<geometry text>')<br><br>e.g. For a river labelling it may be expected that either the labels are<br>only show when the river object is visible in some applications, but for a<br>
cartographic map tiling generation (where consistency is needed) the label<br>should show even if the river is on the adjacent tile but the label geom is<br>on this tile.<br><br>--<br>View this message in context: <a href="http://osgeo-org.1803224.n2.nabble.com/Object-and-Association-Support-tp5325810p5328676.html" target="_blank">http://osgeo-org.1803224.n2.nabble.com/Object-and-Association-Support-tp5325810p5328676.html</a><br>
Sent from the FDO Users mailing list archive at Nabble.com.<br>_______________________________________________<br>fdo-users mailing list<br><a href="mailto:fdo-users@lists.osgeo.org">fdo-users@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/fdo-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-users</a><br>
_______________________________________________<br>fdo-users mailing list<br><a href="mailto:fdo-users@lists.osgeo.org">fdo-users@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/fdo-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-users</a><br>
_______________________________________________<br>fdo-users mailing list<br><a href="mailto:fdo-users@lists.osgeo.org">fdo-users@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/fdo-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-users</a><br>
<br></blockquote></div><br>