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.... ------------------------------------------------------------------------- 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
