[Fwd: RE: implementing a large table over a database]
Gopi Krishna Bhavaraju
gopi____pspl.co.in
Wed Mar 26 16:33:16 CET 2003
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
> > --------------------------------------------------------------
> > ------------------
> >
> >
> >
> >
More information about the AGENTPP
mailing list