Differences

This shows you the differences between two versions of the page.

--- devel:blueprints:ipdevpoll [2009/07/13 14:04] – klette
+++ devel:blueprints:ipdevpoll [2012/05/07 11:26] (current) – fix url morten
@@ Line 1: / Line 1: @@
 ====== ipdevpoll design specification ======
+**This page is currently being updated to match whats being developed. Dont trust this stuff just yet :-)**
 ===== Introduction =====
 //ipdevpoll// is the planned replacement for getDeviceData, becoming the third generation SNMP polling framework for NAV.  This page will lay out the various design ideas and specifications for the new program.
@@ Line 40: / Line 43: @@
 Data is provided through the use of shadow-classes of django-models. Plugins never write django-objects directly. This is handled by the job the plugin runs in at the end of each job.
-Shadow-classes are created in ''nav.ipdevpoll.storage''
+Shadow-classes are created in ''nav.ipdevpoll.shadows''
 \\
 Example shadowclass specification
@@ Line 49: / Line 52: @@
 </code>
-The Shadow-class has two important attributes. ''__shadowclass__'' specifies
+The Shadow-class has two important attributes. ''<nowiki>__shadowclass__</nowiki>'' specifies
 which django model to mimic. This will make any instances of the shadowclass
 answers to the same attributes as the django model. When a property is changed
@@ Line 55: / Line 58: @@
 determining wheter to update an object or not at the end of a run. To lookup
 existing objects in the database the storage system first tries the primary key
-field on the object. If the PK is None, the ''__lookup__''-attribute is used
+field on the object. If the PK is None, the ''<nowiki>__lookup__</nowiki>''-attribute is used
-for the checking. The ''__lookup__'' attribute is a list of strings and tuples.
+for the checking. The ''<nowiki>__lookup__</nowiki>'' attribute is a list of strings and tuples.
 Tuples specifies combined lookups, while strings specifies single field
 lookups. The different lookups are tried in the order they are defined in the
@@ Line 73: / Line 76: @@
 Deletion of objects in the database is done if the shadowobject has its
 ''delete''-property set to True.
+Once the job is done the storage routine is called. The storage system then parses all
+the shadow objects contained in ''job_handler.container'' and make s sure all foreignkeys needed for the storing
+an instance are saved before the object it self.
 ==== Plugins ====
@@ Line 186: / Line 193: @@
 === Implemented plugins ===
-Already implemented plugins can be found on [[devel:ipdevpollplugins]]
+Already implemented plugins can be found on [[devel:ipdevpoll:plugins]]
 ===== Database changes =====
@@ Line 204: / Line 211: @@
 The IF-MIB has no concept of an interface/module relationship.  Information about such a relationship will most likely come from proprietary MIBs (or possibly a properly populated ENTITY-MIB), and should be treated as a bonus if found.  Ie. NAV's model should add to the interface table a mandatory foreign key to netbox,  and only an optional foreign key into the module table.
-===== Code =====
+===== Status =====
-The mercurial repositories can be found at http://metanav.uninett.no/hg/features/ipdevpoll/
+The first NAV release to include ipdevpoll was version 3.6.
 ===== References =====