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

[James Porter]

On Thu, 2010-10-28 at 18:58 -0400, seol at scorec.rpi.edu wrote:
> > On Thu, 2010-10-28 at 03:12 -0400, seol at scorec.rpi.edu wrote:
> >> 4. adding "EntArr" to "Relation Type" and removing iRel_getEntSetIter & iRel_getEntArrSetIterArr
> >>
> >>    CURRENT Relation Type: Ent, Set, Both (Ent&Set)
> >>    NEW: Ent, Set, Both (Ent&Set), EntArr
> >
> > Assuming we end up agreeing that directly encoding one-to-many
> > relationships in iRel (instead of relying on iMesh/iGeom to give us this
> > though sets and/or iterators), I don't think this is a good way to go
> > about doing it as it's really just a hack to work around implementations
> > that don't support sets.
> 
> vice versa. supporting set-only relation type is not a good way either as it requires a hack to work around
> implementation that don't use sets as a way of grouping of multiple data

You're talking about hacks to an implementation. I mean hacks to the
interface; the EntArr proposal seems to be operating under the premise
that we shouldn't change any of the other parts of iRel to help you guys
out, so you have to "bolt on" a new feature. Really, the current way
isn't good for you guys, but EntArr doesn't help us in any way. We'd end
up with two parallel interfaces that the "other guys" would have no use
for except as a compatibility layer.

The problem here is that iRel obviously needs to support a one-to-many
relation *somehow*, and currently, it tries to do this by piggybacking
on sets from iMesh/iGeom. That's what the "Set" relation type is.
Obviously this is bad for implementations that don't use sets, but I
think it's bad in general. It makes the implementation less clear, and
if we want to support one-to-many relations (without deferring
*completely* to iMesh/iGeom sets), we should commit to that instead of
doing it partway (EntArr doesn't help one-to-many-sets, for instance).

Besides, there's no logical difference between "RelationType = {Ent,
Set, EntArr, SetArr}" and "RelationType = {Ent, Set}, CardinalityType =
{One, Many}"*, but the latter way pushes iRel closer to "traditional"
relational DBs, which can only be a good thing, if for no other reason
than that it's easier to write documentation for.

* I'm ignoring Both for now, just for simplicity.

> > Don't take the above suggestion as endorsement, though. As the
> > maintainer of (currently) the only iRel implementation, I should note
> > that doing this (either your way or mine) will significantly increase
> > the complexity and decrease the potential for interoperability** of iRel
> > unless the iMesh and iGeom specs are updated as well.
> 
> It's not clear why not having EntArr relation type. Please describe the following.
>   - how iRel, iMesh and iGeom should be updated further by having EntArr relation type.

Again, I'm not saying that something equivalent to "EntArr" is bad, but
that calling it that is limiting to us (there's no "SetArr"). Pulling it
out into a "cardinality" flag does the same thing but reads better.

However, either EntArr or my cardinality alternative would require us to
significantly change how our iRel implementation works. If we stick with
represent "many" as just a set, then we have to add a lot of extra logic
to handle creating a one-to-many relation that isn't already backed by a
set. The code for EntEntArr relations is already fairly brittle in
Lasso, and I'd rather it not get worse.

The "clean" alternative is to store the "many" directly on a tag, but
that would mean we need variable-length tags in iMesh/iGeom or we have
to fall back to MOAB's native interface, which would make it more
difficult to use Lasso with any other implementation (or to port it
over).

>   - why EntArr and Set are not othorgonal so iRel shouldn't have EntArr relation type losing the generality (limiting
> its capability to support one-to-(set)many only).

I'm not sure what exactly you mean by this, but if two things are
orthogonal, as you seem to be suggesting, I think it makes sense for
them to be represented as different parameters.

>   - why MOAB/Lasso cannot support EntArr relation type to account for FMDB-like implementation as we do support set
> relation type to account for MOAB-like implementation in all other interfaces.

I haven't said that we can't do this, only that it makes things
significantly more complicated for us. As I already mentioned, my
alternative doesn't actually make things any simpler for us, it just
makes the interface clearer.

- Jim