[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOS Row Operations (and other documents)


Robert Story wrote:
> I think there will always be a need for RowStatus-like objects. Even if we
> move creation/deletion into the protocol level, the active and notInService
> states are useful in many cases. And agents with tight memory constraints
> will still need createAndWait for tables with lots of rows.

I think I can imagine a RowStatusThing that only includes
"state" indicators (i.e. Active, NotInService, NotReady).

I'm not sure createAndWait is strictly needed, because depending
on table design, you can still enable use of traditional
SETS to create a row in a table using multiple SETS:

fooTable {fooIndex, fooInt, fooOid, fooRowStatusThing} (read-create)

   SET(fooEntry.fooInt.index = 3

      (row now contains a fooInt=3 and a status object = NotReady or
       NotInService, and it might even contain a fooOid with a DEFVAL)

   SET (fooEntry.fooOid.index = enterprises.acme)

      (status object now = NotInService if the row is capable of going

   SET (fooEntry.fooRowStatusThing.index = Active)

Or you could use a SetRow:

   SetRow(CREATE, fooEntry, index, fooInt=3, fooOid=0.0,

That SetRow might fail if the row can't go active or get created, or
the row might get created and have any legal status as is appropriate.
It all depends on how the fooRowStatusThing object is designed (much
in the same way we now have to include semantic info in the
descriptions for RowStatus).

Then to delete a row:

   SetRow(DELETE, fooEntry, index)

And using a conventional SET:

   SET (fooEntry.fooRowStatusThing.index = NotReady)

As per RFC1903 (RowStatus timeout feature), if you
do nothing further to that row, because it is
in a non-active state, the implementation can then
delete the row after a timeout expires.  Not perfect
in this case, but it works.

So, yes.  I agree that some form of RowStatus-like
thing might be required, but I'm not 100% sure it MUST
include any creation/deletion indicators.  Anyone

I think SetRow probably also works with the current
RowStatus too.  Even if you did a SetRow(CREATE, RowStatus=destroy),
you'd get no error since it's sort of a no-op (same as SETting
a non-existant rowStatus to destroy).

Of course, this does not discuss possible benefits of
SetRow (i.e. OID suppression) over SET, but just to see
if it might "work" (does it?).