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

[Jason Kraftcheck]

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.