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. [Netdot - Feature #1756] Migration to Pg ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Fri, 4 Apr 2014 11:58:57 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Feature #1756] Migration to Pg
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1756 has been updated by Carlos Vicente.
Hello Nick,
Thank you for the feedback. I see your point, but let me explain a few things.
The decision to move to Pg was not secret. We actually made the proposal in the
mailing lists and the FB page long ago. Most people were either in favor, or
not opposed to the changes, so we decided to move ahead with the idea. We are
now very close to having working code (thanks Anton).
Abstracting the DB layer by using an ORM (Class::DBI) was a goal since the
beginning. However, in practice, we found that the abstraction had limitations.
There were several parts of the code that had to be optimized, which required
taking advantage of a MySQL or Pg-specific feature. The latest of these cases
was the maintenance of the IP binary trees (or "tries"). The current
implementation using Net::Patricia works, but is complex and error prone. Using
Pg-specific data types will significantly simplify and speed up IP operations
because Pg will take care of it. Fewer dependencies. No need to cache binary
data. Etc. Another example is schema migrations. Each little change has to be
written twice. More opportunities to make mistakes. Yes, there are some
libraries that supposedly abstract schema changes too, but they also bring more
complexity to the mix.
I'm not saying it's impossible, but supporting both databases inevitably
requires more resources, which we don't have.
I am aware that you maintain the FreeBSD port, and I'm very thankful for that.
Best regards,
cv
Nick Hilliard wrote:
> i understand the attraction of using postgresql's inet/cidr/macaddr data
> types, but from a user perspective this is a major regression.
>
> most people already have dependencies on mysql for other packages, so if
> netdot demands postgresql, it means that these people will end up having to
> run multiple databases. Bear in mind that netdot's target audience are
> network heads, not server people. Lower barriers to using netdot are a good
> thing to aim for.
>
> Can I suggest that if you're planning to support postgresql, you use a query
> abstraction layer to handle cidr/inet queries so that postgresql queries will
> run efficiently, and mysql queries will continue to work (with adequate
> performance for small installations)?
----------------------------------------
Feature #1756: Migration to Pg
https://osl.uoregon.edu/redmine/issues/1756#change-3161
Author: Carlos Vicente
Status: New
Priority: Normal
Assignee: Anton Berezin
Category: Netdot
Target version: 1.0.6
Resolution:
As discussed previously, we would like to start supporting PostgresQL only.
This ticket will track the migration tasks, which include:
* Using Pg's native support for IPv4 and IPv6 addresses
* Using table partitions to keep forwarding and ARP tables for longer
* Remove MySQL-specific pieces of code
* Write script to migrate the data
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
End of Netdot-devel Digest, Vol 85, Issue 2
*******************************************
