[racktables-users] Re: Additional fields on networks

  • From: Olivier Contant <Olivier.Contant@xxxxxxxxxxxxxxxxx>
  • To: "racktables-users@xxxxxxxxxxxxx" <racktables-users@xxxxxxxxxxxxx>
  • Date: Wed, 9 Apr 2014 18:07:44 +0000

By example, I created my own ID for object type in my dictionary and I could 
have end up using those numbers.  Particularly that they are close to the 50 
000 and it would be the first number anyone would use instinctively.  

Even if it doesn't create corruption, it is still not very user friendly for 
the non technical user.  It would make your plugin not working and the user 
would be clueless about why or what he is doing wrong.  

Overall, programming without taking in consideration error is like driving a 
car without break and wheel. 


By the way, don't take it wrong, this is just my personal opinion and I thought 
that would be a good improvement for your script.  

Otherwise, thanks for this plugin, it will come handy :) 

Olivier Contant
System Administrator, Triton Digital

1440 Ste-Catherine W., Suite 1200 | Montreal, Qc, H3G 1R8
Tel.: +1.514.448.4037 #2771 | Toll-Free: +1.866.448.4037 #2771
olivier.contant@xxxxxxxxxxxxxxxxx



-----Original Message-----
From: racktables-users-bounce@xxxxxxxxxxxxx 
[mailto:racktables-users-bounce@xxxxxxxxxxxxx] On Behalf Of Alexey Andrianov
Sent: Wednesday, April 09, 2014 12:23 PM
To: racktables-users@xxxxxxxxxxxxx
Subject: [racktables-users] Re: Additional fields on networks

There would no any data corruption, SQL INSERT would simply fail. Also, those 
IDs are not object IDs, but object type ids. The range 1-50000 is reserved for 
upstream dictionary items which grow their numbers sequentially and now are 
somewhere around 2500.

Anyway, if you have a better solution, please share.

09.04.2014 19:25, Olivier Contant wrote:
> Your SQL query to add the object to dictionary is dangerous.  You should 
> either use a mysql function to find the next ID available or list the table 
> and fetch the next available ID.  By forcing a static ID, you risk to have a 
> user with 49000 and 49001 already in use and create some corruption.
>

--
Best regards,
Alexey



Other related posts: