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

[James Porter]

On Tue, 2010-11-02 at 22:46 -0400, seol at scorec.rpi.edu wrote:
> >
> > 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.
> >
> 
> As long as you have "EntArr==Set" concept in mind

At no point did I say or imply this, except for the obvious part that
each of them contains multiple entities.

I must admit, I'm a bit confused as to why we're discussing this again,
as I thought the direct communication between you (Seegyoung) and I had
gotten us closer to agreement. I know we still had some differences
regarding whether SetArr was worthwhile, but I took your comment,
"Adding cardinality will work as long as iRel supports 'EntArr' neatly
and definitely," as tentative approval.

Since it seems we're back to discussing this on the mailing list, let me
emphasize this for everyone else's benefit: using cardinality to
represent one-to-many-ents should do exactly the same thing as adding an
EntArr relation type, except that it would also add one-to-many-sets. My
reasoning for this is described below (I'm afraid it's rather long).

>  which is not in none of other itaps interface, you are not making any contribution to this itaps project.

I have offered interface suggestions that provide the functionality you
require in a way that minimizes "strangeness" to set-based
implementations as well as using established terminology in relational
database theory. iRel is a relational database; hence the name.* I have
yet to hear a good argument against using the established terminology in
a 40 year old field.

* I suppose, depending on your interpretation, you might consider iRel
just the "relational" part and iMesh/iGeom the "database" part, but this
is splitting hairs, and probably not conducive to any real progress on
this.

>  I strongly recommend to look at iMesh/iGeom spec before you propose
> "inconsistent iRel spec change". As far as remember, you proposed iRel
> change twice which is not very much related to the existing itaps
> interfaces.

I know the details of all the ITAPS interfaces (excluding iField, but
that's not finalized anyway). I've worked with all the interfaces in the
process of implementing Python versions of them in a way that (I and
hopefully my users believe) maintains the interfaces' designs but takes
advantage of higher-level language facilities. That does not, however,
mean that I'm automatically going to imitate iGeom/iMesh in iRel without
good reason.

As a side note, I would of course be interested to see how well the
Python wrappers work with other ITAPS implementations, but I have had
continued difficulty in eliciting a response from the list about this or
other topics. If people are curious about this, feel free to email me
directly.

>   - one is about removing all non-one-to-one functions where we are
> not even set with classification support issue.

This was because the non-one-to-one support was ill-defined in the iRel
specification (unless there's some double-secret documentation that no
one has told me about), and I proposed that for the simple reason that
it's easier to remove something than to add something new.

Unfortunately, I'm not able to account for all implementations in my
proposals because I don't know how they are implemented. A document
describing important performance characteristics of ITAPS
implementations would be immensely helpful for resolving this. Does such
a thing exist, and if not, what's the best way to get people to
contribute to it?

>   - the other is having three Relation Types {ENT,ENTARR,SET} and four
> cardinality {one-one, one-many, many-one, many-many} which results in
> total sixteen combinations although you don't know how they are
> useful.

Is there an error somewhere in this sentence? For one thing, I never
proposed having three relation types; I've said that several times now,
and even provided a proposed C API for it**. For another 3*3*4 is 36.
But 2*2*4 (for 2 RelationTypes on each side) *is* 16, so I'm not sure
which part is in error.

Besides that, your way has 9 cases and mine has 12 when you don't count
many-to-one (which is equivalent to one-to-many anyway). As much as I'm
in favor of reducing testing matrices, I prefer having theoretical
completeness (see above regarding relational database theory).

Incidentally, I've made several other iRel proposals, including small
changes (naming, bug-fixes to interface functions) and larger changes
(removing iRel_getRelatedInterfaces in favor of iRel_findPairs). Of
course, even in small cases, I had the same problem where no one replied
to my proposals until I threatened to take silence as approval of said
changes.

** To reiterate: my proposal was RelationType={ENT, SET},
Cardinality={ONE_TO_ONE, ONE_TO_MANY, MANY_TO_ONE, MANY_TO_MANY}

> Tell me what are "useless two parallel interfaces" you ended up due to
> "OTHER GUYS".

Set-based implementations would use the Set relation type; non-set-based
implementations would use the EntArr relation type. As a result, the
former group would use getEntSetRelation, and the latter group would use
getEntEntArrRelation. With the exception of managing iRel_Instance and
iRel_PairHandles, these two groups would be using a mutually exclusive
set of functions. The only time there would be crossover is when one
group used the other's client code.

I'm trying to avoid that by making functions like getEntEntArrRelation
more attractive to set-based implementations. If Lasso implemented
one-to-many relations (what you'd call "EntArr"), it would probably use
sets internally for performance. In this case, "EntArr" would be a
misnomer because we wouldn't be using entity arrays. I think it would be
preferable if the interface didn't outright lie to the user.

In conclusion, if we make "EntArr" a little more abstract by using
Cardinality, I think we can define the iRel interface such that all
implementations can support one-to-many relations the same way with
decent performance, meaning that client code will work *well* (as
opposed to just working at all) with any ITAPS implementation with
minimal changes.

- Jim