I have upgraded to NAV 3.1.0 and I got a problem with accessing EDITDB Mod_python error: "PythonHandler editdb" Traceback (most recent call last): File "/usr/lib/python2.2/site-packages/mod_python/apache.py", line 287, in HandlerDispatch log=debug) File "/usr/lib/python2.2/site-packages/mod_python/apache.py", line 457, in import_module module = imp.load_module(mname, f, p, d) File "/usr/local/nav/apache/webroot/editdb/editdb.py", line 29, in ? import editTables,nav.Snmp,sys,re,copy,initBox,forgetSQL,nav.web File "/usr/local/nav/lib/python/nav/Snmp.py", line 33, in ? from pysnmp import role, v1, v2c, asn1 ImportError: cannot import name role Can anyone tell me how to solve this problem? best regards Jan Susegg North-Trondelag University College

From kreide at gmail.com Mon Jul 3 15:26:46 2006 From: kreide at gmail.com (Kristian Eide) Date: Mon Jul 3 14:26:51 2006 Subject: [Nav-users] Announcement: NAV 3.1.0 is out In-Reply-To: <44A8D9E2.6070700@uninett.no> References: <8EEE7738AEDF6947B3E5508A0244D1C2A36A31@stam.himolde.no> <44A8D9E2.6070700@uninett.no> Message-ID: <b4c110fd0607030526s6ad2e098pacb80842a69cbed0@mail.gmail.com>

So the tricky part now is to figure out which changes you've already included in your database, and which ones you may have overlooked

NAV really needs to get a proper version system for its schema changes or it will be very hard to manage such changes in any reasonable way (manually creating sql patch scripts is not the way to go). -- Kristian

From roar.pettersen at uib.no Mon Jul 3 15:45:17 2006 From: roar.pettersen at uib.no (Roar Pettersen) Date: Mon Jul 3 14:45:22 2006 Subject: [Nav-users] Editdb error In-Reply-To: <8A65B72C71E7484FBE1862045AAC5A8FB73D20@embla.ansatt.hint.no> References: <8A65B72C71E7484FBE1862045AAC5A8FB73D20@embla.ansatt.hint.no> Message-ID: <Pine.SOC.4.64.0607031442450.1934@alf.uib.no>

Hello !

Can anyone tell me how to solve this problem?

I had exacly the same problem. :-) You have a missmatch in the pysnmp library when you downgraded from pysnmp-3.3.5 to 2.0.8. My solution was to delete /usr/local/lib/python2.4/site-packages/pysnmp/ and install the pysnmp-2.0.8 again. -- Med vennlig hilsen / Regards; Roar Pettersen Universitetet i Bergen - The University of Bergen Nygardsgt. 5 - N-5020 BERGEN - Norway Tlf: +47 55 58 40 55 VIP: 81503 fax: +47 55 58 40 70 roar.pettersen@it.uib.no - IT-Avd, UiB - http://www.uib.no

From morten.vold at uninett.no Mon Jul 3 15:51:23 2006 From: morten.vold at uninett.no (Morten Vold) Date: Mon Jul 3 14:51:33 2006 Subject: [Nav-users] Announcement: NAV 3.1.0 is out In-Reply-To: <b4c110fd0607030526s6ad2e098pacb80842a69cbed0@mail.gmail.com> References: <8EEE7738AEDF6947B3E5508A0244D1C2A36A31@stam.himolde.no> <44A8D9E2.6070700@uninett.no> <b4c110fd0607030526s6ad2e098pacb80842a69cbed0@mail.gmail.com> Message-ID: <44A912CB.1050904@uninett.no>

Kristian Eide wrote:

NAV really needs to get a proper version system for its schema changes or it will be very hard to manage such changes in any reasonable way (manually creating sql patch scripts is not the way to go).

Interesting observation, Kristian, but your advice isn't very helpful without any examples or concrete ideas. What, in your opinion, is a "proper version system for schema changes"? My take on this is that schema changes are relatively few and far apart in NAV today. Therefore I don't see the need to invest a lot of time into devising some elaborate system to avoid having to manually write sql patch scripts. My suggestions is rather to implement a project policy to commit patch scripts along with any schema alterations. That way, a poor release coordinator (me) won't have to piece together every schema change that took place since the last release, and produce a whopping mishmash of hopefully consistent SQL upgrade statements on each release. Also, this should solve the problem for the few who might be using bleeding edge code from trunk at all times. They might not all be SQL wizards, able to analyze the changes and whip up their own SQL statements to change the schema, but each revision that updates the schema will come with an up-to-date upgrade script. We've never claimed that tracking the development trunk should be a piece-of-cake, though. -- mvh Morten Vold UNINETT