RS> The array-user helper is pretty insistent about doing the insertion
RS> (other than at startup) and deletion for you.
OK - that's useful to know. Thanks.
DS> What's the approved way for removing a row using this helper?
RS> If you look at the helper code, during a commit it checks the
RS> ag->row_deleted and ag->row_created flags to make decisions
RS> about inserting and deleting rows. So setting the row_deleted
RS> flag in the action phase or earlier should get the row removed
RS> from the container.
It's as simple as that?
<tap, tap, tap>
So it is! That's *very* good!
RS> a) deleted rows are removed from the container, but delete_row
RS> is not called. So I think deleting rows leaks memory.
Yup - I'd spotted that too. But I'm currently concentrating on
how things are meant to work, rather than picking up on bugs :-)
DS> The 'create_row' hook
DS> seems to activate the automatic creation of rows ... But this
DS> isn't what's needed for a pure RowStatus-controlled table.
RS> Hmm... ok, what is needed?
Well, as I understand it, there are two basic techniques for
creating a new row in a table. One approach is to SET the
value of a missing instance, and for this to trigger the creation
of the corresponding row ("automatic creation").
The other is to SET the relevant RowStatus column instance to
either 'createAndWait' or 'createAndGo', and for *this* to be
the trigger for creating the row. So a SET request that just
assigned to a missing instance (but didn't include a suitable
'createAnd...' assignment) should fail.
Either is a perfectly valid mechanism, so I'm looking at describing
how to implement things either way. I know Wes is strongly in
favour of the first approach, but I believe this decision should
be left to the module implementor, and not enforced by the toolkit.
Remember too that I'm looking to provide an understand of *how*
each helper works, rather than just a simple description of
the code that's generated. So I've been trying to strip down the
various array-user examples to the absolute minimum amount of code.
In doing so, it became clear that simply defining a 'create_row'
hook was sufficient to support the first ("automatic creation")
approach - I didn't need to set the 'ag->row_created' flag myself.
But with a pure RowStatus implementation, I don't *want* the row
to be created unless something (the RS-handling routine) explicitly
sets the 'ag->row_created' flag to trigger it.
Now I may have misunderstood how the 'create_row' routine is being
invoked, but it looks as if it's being a little too trigger happy.
Unless there's a way to calm it down a bit?
Dave
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
