Send Netdot-devel mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://osl.uoregon.edu/mailman/listinfo/netdot-devel
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-devel digest..."


Today's Topics:

   1. latest etc/default_data with beginning checksum dbb47a09 on
      the master branch (William Bulley)
   2. [SCM] Netdot branch netdot-1.0 updated.
      netdot-1.0.5-rc1-13-gbed5323 ([email protected])
   3. Re: latest etc/default_data with beginning checksum       dbb47a09
      on the master branch (Carlos Vicente)


----------------------------------------------------------------------

Message: 1
Date: Wed, 12 Mar 2014 10:57:10 -0400
From: William Bulley <[email protected]>
Subject: [Netdot-devel] latest etc/default_data with beginning
        checksum dbb47a09 on the master branch
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

I found the issues described below studying the v1.0.4 etc/default_data
file, but little has changed with that file of recent.

On lines 36 through 58 plus line 61, there are 24 rows INSERTed into
the Entity table of the Netdot database.  These rows represent, for the
most part, the names of several well known network industry equipment
manufacturers.  Yet one can see from studying lines 28 through 34 that
the Entity table is capable of storing seven different types of entities,
namely: Branch, Customer, Department, Manufacturer, Peer, Provider, and Vendor.

To associate the 24 Entity table entries at Netdot installation time with
those seven types, there are eight INSERT statements in lines 63 through
70 to populate the EntityRole join table initial rows..

The first seven rows being added associate the first seven Entity table
rows with the type "Manufacturer" (4).  The eighth INSERT associates the
eighth Entity table row with "Department" (3).

It looks like Netdot at one time in the past had only seven manfacturers
INSERTed into the Entity table.  The eighth INSERT was for the Network
Services department at Oregon.  I suggest that the first seven INSERT
statments starting at line 63 be extended to twenty-three (23) INSERT
statements:

  INSERT INTO entityrole (entity,type) VALUES ('1', '4');
  :
  :
  INSERT INTO entityrole (entity,type) VALUES ('23', '4');

and the current eighth INSERT statement be changed to a final
twenty-fourth (24) INSERT statment as so:

  INSERT INTO entityrole (entity,type) VALUES ('24', '3');

in order to accommodate the Network Services entity INSERTed on line 61.

 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

In addition, I have found that despite there being a "Cisco" entry
(INSERTed on line 37) and a "Juniper" entry (INSERTed on line 48),
when I add a Cisco or Juniper device via an SNMP query, additional
rows are added to the Entity table as "cisco" and "juniper",
respectively.  I have not checked this (it is a minor nit), but I
suspect there is a test (insert_or_update() method?) that does not
consider mixed cases for the manufacture name string during device
updating.  I believe these minor changes could be added to the git
master branch without causing any side-effects for anyone.  Thanks.

Regards,

web...

-- 
William Bulley                     Email: [email protected]

72 characters width template ----------------------------------------->|


------------------------------

Message: 2
Date: Wed, 12 Mar 2014 08:59:21 -0700
From: [email protected]
Subject: [Netdot-devel] [SCM] Netdot branch netdot-1.0 updated.
        netdot-1.0.5-rc1-13-gbed5323
To: [email protected]
Message-ID: <[email protected]>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Netdot".

The branch, netdot-1.0 has been updated
       via  bed532320ade03d4588e67e930fc1bbd87342a3b (commit)
       via  577b69695d24ce8f5c4aac8236d6aeb459b45562 (commit)
       via  ad1659bbdf8864a20e47860e71de215e25ffa5cc (commit)
      from  73cffc66065c3a6c2f7db4da2ba80bd6772a6d8d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit bed532320ade03d4588e67e930fc1bbd87342a3b
Author: Carlos Vicente <[email protected]>
Date:   Wed Mar 12 11:59:10 2014 -0400

    Fix default entity roles at installation time

diff --git a/etc/default_data b/etc/default_data
index 7b9c522..b4e0a71 100755
--- a/etc/default_data
+++ b/etc/default_data
@@ -67,7 +67,24 @@ INSERT INTO entityrole (entity,type) VALUES ('4', '4');
 INSERT INTO entityrole (entity,type) VALUES ('5', '4');
 INSERT INTO entityrole (entity,type) VALUES ('6', '4');
 INSERT INTO entityrole (entity,type) VALUES ('7', '4');
-INSERT INTO entityrole (entity,type) VALUES ('8', '3');
+INSERT INTO entityrole (entity,type) VALUES ('8', '4');
+INSERT INTO entityrole (entity,type) VALUES ('9', '4');
+INSERT INTO entityrole (entity,type) VALUES ('10', '4');
+INSERT INTO entityrole (entity,type) VALUES ('11', '4');
+INSERT INTO entityrole (entity,type) VALUES ('12', '4');
+INSERT INTO entityrole (entity,type) VALUES ('13', '4');
+INSERT INTO entityrole (entity,type) VALUES ('14', '4');
+INSERT INTO entityrole (entity,type) VALUES ('15', '4');
+INSERT INTO entityrole (entity,type) VALUES ('16', '4');
+INSERT INTO entityrole (entity,type) VALUES ('17', '4');
+INSERT INTO entityrole (entity,type) VALUES ('18', '4');
+INSERT INTO entityrole (entity,type) VALUES ('19', '4');
+INSERT INTO entityrole (entity,type) VALUES ('20', '4');
+INSERT INTO entityrole (entity,type) VALUES ('21', '4');
+INSERT INTO entityrole (entity,type) VALUES ('22', '4');
+INSERT INTO entityrole (entity,type) VALUES ('23', '4');
+INSERT INTO entityrole (entity,type) VALUES ('24', '3');
+
 
 INSERT INTO circuitstatus (name) VALUES ('Active');
 INSERT INTO circuitstatus (name) VALUES ('Disabled');

commit 577b69695d24ce8f5c4aac8236d6aeb459b45562
Author: Carlos Vicente <[email protected]>
Date:   Tue Mar 4 11:21:19 2014 -0500

    Tweak defaults and nullables in datacache table

diff --git a/etc/netdot.meta b/etc/netdot.meta
index df64cc9..b13cf7c 100644
--- a/etc/netdot.meta
+++ b/etc/netdot.meta
@@ -1972,12 +1972,12 @@ $meta = {
         default => '',
         description => 'binary data',
         length => '',
-        nullable => 0,
+        nullable => 1,
         tag => 'Binary Data',
         type => 'longblob'
       },    
       tstamp => {
-        default => '',
+        default => '0',
         description => 'When this data was cached',
         length => '',
         nullable => 0,

-----------------------------------------------------------------------

Summary of changes:
 etc/default_data | 19 ++++++++++++++++++-
 etc/netdot.meta  |  6 +++---
 2 files changed, 21 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
Netdot


------------------------------

Message: 3
Date: Wed, 12 Mar 2014 12:03:58 -0400
From: Carlos Vicente <[email protected]>
Subject: Re: [Netdot-devel] latest etc/default_data with beginning
        checksum        dbb47a09 on the master branch
To: William Bulley <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252

Hi Web,

On Mar 12, 2014, at 10:57 AM, William Bulley <[email protected]> wrote:

> I found the issues described below studying the v1.0.4 etc/default_data
> file, but little has changed with that file of recent.
> 
> On lines 36 through 58 plus line 61, there are 24 rows INSERTed into
> the Entity table of the Netdot database.  These rows represent, for the
> most part, the names of several well known network industry equipment
> manufacturers.  Yet one can see from studying lines 28 through 34 that
> the Entity table is capable of storing seven different types of entities,
> namely: Branch, Customer, Department, Manufacturer, Peer, Provider, and 
> Vendor.
> 
> To associate the 24 Entity table entries at Netdot installation time with
> those seven types, there are eight INSERT statements in lines 63 through
> 70 to populate the EntityRole join table initial rows..
> 
> The first seven rows being added associate the first seven Entity table
> rows with the type "Manufacturer" (4).  The eighth INSERT associates the
> eighth Entity table row with "Department" (3).
> 
> It looks like Netdot at one time in the past had only seven manfacturers
> INSERTed into the Entity table.  The eighth INSERT was for the Network
> Services department at Oregon.  I suggest that the first seven INSERT
> statments starting at line 63 be extended to twenty-three (23) INSERT
> statements:
> 
>  INSERT INTO entityrole (entity,type) VALUES ('1', '4');
>  :
>  :
>  INSERT INTO entityrole (entity,type) VALUES ('23', '4');
> 
> and the current eighth INSERT statement be changed to a final
> twenty-fourth (24) INSERT statment as so:
> 
>  INSERT INTO entityrole (entity,type) VALUES ('24', '3');
> 
> in order to accommodate the Network Services entity INSERTed on line 61.
> 


Good catch. Thank you. I?ve submitted the changes to the repo. 


> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
> 
> In addition, I have found that despite there being a "Cisco" entry
> (INSERTed on line 37) and a "Juniper" entry (INSERTed on line 48),
> when I add a Cisco or Juniper device via an SNMP query, additional
> rows are added to the Entity table as "cisco" and "juniper",
> respectively.  I have not checked this (it is a minor nit), but I
> suspect there is a test (insert_or_update() method?) that does not
> consider mixed cases for the manufacture name string during device
> updating.  I believe these minor changes could be added to the git
> master branch without causing any side-effects for anyone.  Thanks.
> 
> 

I imagine you are using Pg. I remember finding this difference between Pg and 
MySQL (MySQL is not case-sensitive by default, but Pg is), and I remember 
applying some fix for this, but obviously I?ll have to go back and dig more.

Anton, if you are reading this, let me know if you have any input on the 
subject.

Thanks,

cv


------------------------------

_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel


End of Netdot-devel Digest, Vol 84, Issue 2
*******************************************

Reply via email to