[Fwd: RE: implementing a large table over a database]

[Frank Fock]

Hi Gopi,

There are several things I do not understand
from your positing:

1. What are sub-tables? How do you define a
    "sub-table"?
2. Where in the original postings you quoted
    is stated that a table should only be updated
    when a search on a previous table has failed?
    (The opposite is true, the MibTable::update
    method has to be overridden for each table
    with dynamic row allocation)
3. Why do you think that it does not work?
    Can you give an example?

Best regards,
Frank Fock

Gopi Krishna Bhavaraju wrote:
> Hi all,
> 
> I came across this old posting which talks about adding sub-table rows
> dynamically. In this posting whenever a last row is hit in a table, it
> suggests to register rows for the next sub-table. But with this approach if
> the NMS directly queries (does  only sub-table walk) the next sub-table, no
> rows corresponding to it will be shown. So, is this is correct way of
> registering sub-table rows dynamically?
> 
> I would appreciate your help on this.
> 
> Thanks,
> --Gopi.
> 
> 
> 
>>-------- Original Message --------
>>Subject: RE: implementing a large table over a database
>>Date: Fri, 1 Nov 2002 10:50:44 -0800
>>From: Alex Finogenov <afino____Malibunetworks.com>
>>CC: agentpp-dl____agentpp.com
>>
>>Guys,
>>
>>Depending on your design, you may have to load the first row after
>>hitting
>>the last row values in the database. This is because you may have to
>>wrap
>>around to return the values of the next column from the first row in the
>>table.
>>
>>Alex F.
>>
>>
>>>-----Original Message-----
>>>From: Dave Mason [mailto:dmason____transat-tech.com]
>>>Sent: Friday, November 01, 2002 9:39 AM
>>>To: Martin Janzen; Alex Finogenov
>>>Cc: agentpp-dl____agentpp.com
>>>Subject: Re: implementing a large table over a database
>>>
>>>
>>>  Wow - yall are great!  The odds of my coming up with that
>>>in the usual
>>>short time were pretty slim.  Just a quick follow-up, I
>>>assume loadRow
>>>and loadNextRow are similar except the first loads the row
>>>specified by
>>>the index argument, but loadNextRow loads the row following the one
>>>specified by the argument?   That is, loadNextRow loads the row that
>>>find_succ is going to find.  (It seems like loadNextRow
>>>should actually
>>>call find_succ, but I can see you dont want to go there...)  Also, I
>>>assume all they need to do is build a MibTableRow in the
>>>usual manner,
>>>with all the columnar objects created and initialized correctly, and
>>>assign the row to the MibTable.
>>>
>>>Luckily my table is read-only, so I'll leave the rest for future
>>>generations. :)  Thanks again for your help,
>>>
>>>Dave
>>>
>>>Martin Janzen wrote:
>>>
>>>
>>>>[Not sure this was sent earlier; sorry if you see it twice...]
>>>>
>>>>Our resident external-tables expert, Alex Finogenov, wrote:
>>>>
>>>>
>>>>>[...]
>>>>>2. I implemented GetBulk in terms of GetNext. You will
>>>
>>>have to override
>>>
>>>>>MibTable::find_succ(), which is called by during the
>>>
>>>processing of
>>>
>>>>either
>>>>
>>>>>method, if I remember correctly.
>>>>
>>>>I've also found that this works pretty well.  It's a lot easier than
>>>>trying to make the update() method anticipate the exact set of rows
>>>>that will be needed by a complex GETBULK request.
>>>>
>>>>However, I notice that if I override find_succ(), my update() method
>>>>still has to check for the case in which a GETNEXT/GETBULK from a
>>>>previous table has run over into the current table.  If
>>>
>>>this happens,
>>>
>>>>it must load the first row of the table, so that Agent++
>>>
>>>knows there's
>>>
>>>>something there.
>>>>
>>>>(The first row is sufficient: Once it knows that it must
>>>
>>>descend into
>>>
>>>>the current table, Agent++ will continue to call
>>>
>>>find_succ() as needed.)
>>>
>>>>
>>>>In other words, here's a pseudocode version of what I'm doing now:
>>>>
>>>>void
>>>>MyTable::update(Agentpp::Request* pReq)
>>>>{
>>>>    // Don't do more work than necessary.  (Note that it's
>>>
>>>good practice
>>>
>>>>    // to check both the request address and the
>>>
>>>transaction ID, since
>>>
>>>>    // the request address is at the whim of the implementations of
>>>>    // Agent++ and of your new/delete operators.)
>>>>    if ((pReq == mCurrentRequest) &&
>>>>        (pReq->get_transaction_id() == mLastTransactionID)
>>>>        return;
>>>>
>>>>    mCurrentRequest = pReq;
>>>>    mLastTransactionID = (pReq == 0) ? 0 :
>>>
>>>pReq->get_transaction_id();
>>>
>>>>    // Since this is a new request, throw away all rows generated in
>>>>    // response to the previous request.  (I agree with
>>>
>>>Alex: stateless
>>>
>>>>    // agents are the way to go!)
>>>>    clear();
>>>>
>>>>    for (int sub = 0; sub < pReq->subrequests(); sub++)
>>>>    {
>>>>        Agentpp::Oidx subrequestOID = pReq->get_oid(sub);
>>>>
>>>>        switch (pReq->get_type())
>>>>        {
>>>>        case sNMP_PDU_GET:
>>>>            // If the requested OID is in this table,
>>>
>>>create a row for
>>>
>>>>            // the requested index value.
>>>>            if (base(subrequestOID) == *key())
>>>>                loadRow(index(subrequestOID));
>>>>            break;
>>>>
>>>>        case sNMP_PDU_GETNEXT:
>>>>        case sNMP_PDU_GETBULK:
>>>>            // If this table's update() method was called
>>>
>>>in response to
>>>
>>>>            // a GETNEXT request on the last object in a
>>>
>>>previous table,
>>>
>>>>            // load the first row of this table, so that
>>>
>>>Agent++ knows
>>>
>>>>            // it needs to descend into this subtree.
>>>>            if (base(subrequestOID) != *key())
>>>>                loadNextRow(Oidx());
>>>>            break;
>>>>
>>>>        [...]
>>>>
>>>>        }
>>>>    }
>>>>}
>>>>
>>>>Agentpp::Oidx
>>>>MyTable::find_succ(const Agentpp::Oidx& oid, Agentpp::Request* pReq)
>>>>{
>>>>    // Load the row which follows the requested index
>>>
>>>value, then let
>>>
>>>>    // the Agent++ tree traversal code find it as usual.
>>>>    loadNextRow(index(oid));
>>>>    return MibTable::find_succ(oid, pReq);
>>>>}
>>>>
>>>>Comments/suggestions welcome, of course.
>>>>
>>>>
>>>>
>>>>
>>>>>3. Get methods are peanuts comparing to the Set,
>>>
>>>especially in when
>>>
>>>>>implementing tables with AUGMENT clause, etc.
>>>>
>>>>Oh, good.  I can hardly wait...
>>>>
>>>>
>>>
>>>--
>>>--------------------------------------------------------------
>>>------------------
>>>Dave Mason  (817)481-4412 x139 voice, (817)481-4461 fax,
>>>dmason at transat-tech.com
>>>Transat Technologies                180 State St, Suite 240,
>>>Southlake, TX 76092
>>>Integrating 3GSM and WLAN
>>>http://www.transat-tech.com
>>>--------------------------------------------------------------
>>>------------------
>>>
>>>
>>>
>>>
> 
> 
>