[freeside-devel] MSSQL

Nathan Anderson nathana at fsr.com
Fri Oct 6 04:43:26 PDT 2017


Whoa, I hadn't yet subscribed to this list and so did not even see this message until just now...

On Sun, Oct 01, 2017 at 13:45:45 -0700, Ivan Kohler wrote:
> 
> On Sun, Oct 01, 2017 at 03:52:40PM -0400, Nathan Anderson wrote:
> 
> > (People may think this gross ;-) but ultimate goal is 
> > actually to have Freeside talking to MSSQL server by way of 
> > DBD::Sybase.  Perhaps by cleaning up any Postgres-isms this'll also 
> > end up having the side-effect of improving MySQL/MariaDB support, or 
> > at least make it easier to bring up-to-date.)

[snip]

> Without commercial sponsorship, we're probably not interested in 
> reviewing, merging or carrying the maintenance cost of MSSQL support.  
> That would be a lot of time, work and risk.  I don't see any useful 
> benefit for our customers or users.

Well, that is a little disappointing to hear, even if somewhat understandable.  We are interested in Freeside, but for various reasons (some legacy), our interest would be considerably increased if we could host the data on an instance of MSSQL, however distasteful that idea may be to others.  Let's just say that I'm still trying to bring both my boss and co-workers around to the idea of Freeside, and MSSQL support would be a considerable premise in the column of the "pro" argument.

What would you consider to be "commercial sponsorship"?  If all you mean is the time and maintenance of the feature itself, assuming we end up committing to Freeside as an organization, and assuming we are the ones who end up single-handedly bootstrapping MSSQL support from the outset, we would then have a vested interest in carrying on maintenance of this particular feature ourselves for as long as we use the product.  All we would ask in return is that our patches be integrated into the mainline releases, so that when new versions come out we don't have to re-patch every new release from the ground up.  If something happens to break support in a future version, we'd fix it and submit the fix.

As for "benefit for [your] customers or users", I'd argue that anything that helps to make the base Freeside product less dependent on a particular DB platform, the better.  Abstract all that crap away as much as possible so that any underlying storage engine can be substituted for another with just a DSN change.  From what I've seen while diving into the code myself, it might be a while before this is a reality (and admittedly it isn't helped by all of the differences in the various engines...I guess the ANSI standards only cover so much...), but perhaps adding yet another database back-end will be a positive step forward in that direction.
	
I just joined this list because I have actually gotten things to the point (after considerable effort) where 'freeside-setup' now completes with MSSQL on the back-end and is able to successfully populate a database.  I had a couple of question, the answers to which would help me to tie up the remaining loose ends.  The code at this point is still kind of a pile of hacks, but it shouldn't take much to get it beyond that.

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com



More information about the freeside-devel mailing list