[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Robert Story wrote:
> At 5:25 PM -0700 5/1/01, Lauren Heintz wrote:
> >For a SetRow request, if the instancePart of a rowOp is the
> >same as any other rowOp in the same PDU, that is intended to
> >be an error.
> I'm not sure I agree. If the instance part is the same, but the row is
> different (one table AUGMENTS the other), then they are setting different
> attributes of the same row, and thus I would think it would be common that
> they would be in the same PDU. For the case of a simple index, the
> instance inheritance idea doesn't save space, but for longer indexes it
You're right. What I meant to say was, if two identical
rowIdentifiers (where tablePart AND instancePart are both
the same) exist in the same SetRow request...an error occurs.
In the case of creating a row (foo) along with augmented
objects (fum), the tableParts are different so that's not an error
and works good.
> > 1. GetRow (rowId1:foo.row1, op1A=fooInt, op1B=fooUnsigned32)
> >and using your suggestion:
> > 4. GetRow (rowId1=foo.row1, op1A=fooInt, rowId2=1.0:1.0,
> No, what I'm suggesting is that
> could be
> 4.GetRow(rowId1=foo.row1,op1A=fooInt, rowId2=fum.1.0,op1B=fooUnsigned32)
> >Besides I think the 1.0 cannot be distinguished
> >from actual instance values that may be in a vb.value (whereas
> >the 1.0 values in the vb.name can always be distinguished
> >from valid MIB objects).
> That's a good point. How about
> rowIdentifier = <vb.name=tableEntryPart,
I understand, and agree this is a useful optimization.
Also, since the inheritance value for instanceParts would thus
be "NULL", I'm wondering if the inheritance OID for tableParts
should be the NULL OID (0.0) instead of 1.0? I think I have
this as an issue in the appendix. I think 0.0 works just as
well as 1.0 AND may be more intuitive? Any opinions?