OK, good stuff here ..... very helpful ... thanks.
Here are a few more questions ...
I have Table1 (main table) and Table2 ("1394 table" which is an extension of
Table1). Lets say I have updated the Table2_container_init() routine to
indicate that Table2 should use the same cache that Table1 uses. Now, when
the first SNMP request is made and it is for Table2 (ex: "snmpwalk" request
perhaps) then the Table1_container_load() routine will be called. Is this all
correct so far?
Inside the Table1_container_load() routine I will newly allocate all the
required rows as well as assigning an index to each of these rows. If this is
a subsequent call to Table1_container_load() then I will make sure to rebuild
the Table1 from scratch by allocating all new rows, but making sure to use the
same index values for each row as used before. Is this correct so far?
Lets say that Table1 has the following 4 rows (and 2 columns) populated so far:
index=1 type=1394
index=2 type=DVI
index=3 type=1394
index=4 type=Tuner
Now, since this SNMP request was for Table2, then the Table2_row_prep() routine
will eventually be called. This procedure's interface provides a "row_context"
data structure in which I can obtain the specific row index in which this
request is related. I can then simply populate this specific row (from Table1)
with the appropriate Table2 data .... is this correct?
For a "snmpwalk" request will the Table2_row_prep() routine be called only
twice and will the procedure interface supply row_conitext data for row 1 and 3
(since these are the indexes which relate to the 1394 Table2)? I am not sure
how the agent would know which rows of Table1 are being used as extensions for
Table2 data, so maybe you can clarify whether this works or not. If is does
not work like this then perhaps you can tell me how I can determine which row
from Table1 I need to populate with my Table2 data when the Table2_row_prep()
routine is called.
Robert Story <[EMAIL PROTECTED]> wrote: On Mon, 4 Jun 2007 10:30:25 -0700 (PDT)
Need wrote:
NH> 1) Lets say the first request made is to "snmpwalk" through Table2. Are
you saying that Table1's container_load() procedure has never been called yet
so none of the index values have been loaded and none of the rows have been
allocated and placed into the Table1 container yet? If this is true, then how
does an "snmpwalk" through Table2 work since no rows have been allocated to
store the data yet?
By default, yes. Remember, mib2c does not know about the relationship between
the 2 tables, so the generated code treats each independently, with their own
container and data.
NH> I am getting way confused. What actually happens when an "snmpwalk" of
Table2 occurs first? Does the container_load() procedure of Table2 get called
first?
Yes, by default it would. That is why I told you to use a shared cache in my
last message. If each table uses the same cache, they when _any_ of them are
accessed, the will call the table1 container_load function.
NH> What exactly should be placed into the container_load() procedure of
Table2?
Nothing. You could actually delete it, if you also deleted the code that
referenced it in the interface code. With a little work, the mib2c code could
be updated to handle this automatically. Let me know if you want to sponsor a
little work in this area. ;-)
NH> Actually, by now you understand I have a main Table1 (with 4 fields) and a
Table2 (with 8 fields) which is an extension to Table1. Perhaps you can
describe to me what functionality should be placed into the
Table1_container_load(), Table1_row_prep(), Table2_container_load() and
Table2_row_prep() routines? I think my problem is that I understand what the
container_load and row_prep routines should do, but have no idea how to use
them correctly when one of my tables is an extension of another table.
Table1_container_load(): load all the indexes. Optionally, load data context
for tabels 1-N.
Table1_row_prep(): load data context for table 1, if not done in container_load
Table2_container_load(): nothing
Table2_row_prep(): load data context for table 2, if not done in
container_load
NH> 2) You state "Luckily, there is a failry easy way around that, which is
sharing a single cache as well. See the function _ifXTable_container_init to
see how it looks up the ifTable cache to share a container".
NH>
NH> I looked at this code and can see how another table's cache can be
connected to the container of another table. Perhaps you can explain to me
"why" I should be doing this as am I not clear as to why you are recommending
this code to me in the first place.
The cache handler is the one that takes care of loading the container when a
request comes in.
NH> 3) You stated "Now, the problem is that when you are loading the container,
you will have no idea which of the 6 tables triggered the load."
NH>
NH> Well this seems bad since I will not know what I am really loading? Are
you indicating I should not be implementing it this way by adding all fields
into the data_context of Table1? Is this your way of indicating to me that I
will run into too many problems with combining all fields into the data_context
of Table1 and that I should use sub-containers after all?
No, I'm just saying that if you always load data for table1, you could be
wasting time, since the query is actually for table4. So, if populating the
container with all the data is expensive, you might want to just put in the
indexes, and use row_prep for all the tables. On the other hand, if you have
the data for tables 1 and 4 while getting the indexes, you could go ahead and
save that data, since you've already got it. It might be a waste of time, but
hey, you've already got the data.
Remember, there is no ONE way to implement a table. It is highly dependent on
where you get your data from.
NH> 4) I wish you were local so I could stop by and have you simply draw some
ideas on some paper as to what you are recommending.
For the right price, I could be local for a few days. ;-)
The problem is, you happened to have a non-trivial example to start with.
You'll get there....
---------------------------------
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
