iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]

[Mark Shephard]

Jason,

Although those that think "classification" may not be thrilled with 
needing to do things in a somewhat around about fashion, having any way 
the does not kill efficiency can be used. Although others will need to 
study and comment on the suggestions, I think the spirit of what you 
describe below may be on the right path. In addition, as you indicated 
below, I do think that such things are useful to all implementations, 
while being really a central need of others.

If may take a bit of time for the technical guys here to think about the 
various suggestions made and to get back to you, but they will provide 
feedback/suggestions.

Mark

On 10/28/10 6:02 PM, Jason Kraftcheck wrote:
> On 10/28/2010 04:19 PM, James Porter wrote:
>
>>
>> That is what happens now, and it's part of why the behavior for
>> setEntEntArrRelation is bizarre. For instance, what happens when there's
>> no related set on the "Set" side? I think Tim and I agreed that it
>> should currently return an error, but this would be problematic for
>> people who don't want to work with sets.
>>
>> Again, this argument is basically why I'm not endorsing my suggestion
>> (I'm ok with the status quo), but the main difference is that "Set"
>> provides an *indirect* one-to-many relationship, and "EntArr" provides a
>> *direct* one-to-many relationship. That is, in the "Set" case, you have
>> to go through getEntities to get to the "many". Currently, I think the
>> iRel spec is strongly oriented towards using one-to-one relations
>> interally (that's certainly how Lasso does it), with the one-to-many
>> relations being "emulated" by way of already-existing functionality
>> (sets) in iMesh/iGeom. Whether this is a good thing or not depends on
>> what you think of sets.
>>
>> As I mentioned with setEntEntArrRelation, this does potentially change
>> some of the semantics of other functions. The main reason I wanted to
>> get rid of the non-one-to-one functions in iRel is because of this
>> behavior.
>
> RPI doesn't want to do the indirect solution (anything with entity sets) so
> we need some kind of compromise that doesn't require them.  I thought that
> the current setEntEntArrRelation (and related functions) would do that
> without preventing us from implementing this indirectly with sets.
>
>
> I do think that doing things with set handles would be a cleaner interface.
>   So I'm going to try to describe a possible way that RPI could implement
> such a solution without (hopefully) loss of performance.  Of course I have
> no idea about the internal details of FMDB, so this could be completely
> unworkable.  And what you choose to implement and how is obviously none of
> my business.  I'm just sharing an idea that I had.
>
> What if, in FMDB, when asked for the "entity set" in the iMesh API related
> to some entity in the iGeom API, a /special/ entity set handle was passed
> back that didn't correspond to a real, user-defined entity set but rather
> the more abstract idea of "all the mesh entities classified to some
> geometric entity".  Basically, to specify the classification for some
> entity, rather than doing the following:
>    iRel_setEntEntArrRelation( ..., geom_entity, 0, mesh_ent_array, len, ... )
> you instead did:
>    iBase_EntitySetHandle faux_set;
>    iRel_getEntEntRelation( ..., geom_entity, ...,&faux_set, ... );
>    iMesh_addEntArrToSet( ..., mesh_ent_array, len, faux_set, ... );
>
> If there was no "real" entity set (the iRel call returned some special
> handle that just meant mesh for the fifth geometric surface or whatever),
> the cost of that call should be almost nothing.  And if the set handle is
> "special", such that there are no "real" entity sets involved, then the call
> to iMesh_addEntArrToSet shouldn't be any more expensive than the
> iRel_setEntEntArrRelation would have been.
>
> I know that seems a rather round-about and confusing way to do things.  So
> I'll briefly try to explain the core idea at a little bit higher level.  All
> of the functions in the iMesh and iGeom interfaces dealing with entity set
> handles can be split into two groups:
>    1) those that create/destroy entity sets and modify parent/child links
> and
>    2) the rest of the functions.
>
> If we ignore everything in 1) for a minute, then and just look at 2), then
> 2) looks a lot like an API to work with any arbitrary grouping of entities
> that an implementation might have.  Examples could include the group of mesh
> entities classified to some geometric entity or the group of entities in a
> parallel part.  We have a nice API for dealing with collections of entities
> stored on the implementation side of the API*.  And that could still be the
> case even with the functions in 1) if one considers user-defined entity sets
> to be only one of many types of entity groupings stored on the
> implementation side of the interface.
>
> - jason
>
>
> * In fact, I've often wished that there were another type of
> implementation-side grouping that is a kind if transitory set.  If more
> queries and modification routines worked with such 'temporary groups' it
> would simplify a lot of API calls and make complex operations composed of
> passing results of one API call to another much simpler and more efficient.
>
>