Paul Makepeace wrote: > On Fri, May 9, 2008 at 7:30 PM, Lyle <[EMAIL PROTECTED]> wrote: > >> Hi All, >> This last week I've overhauled a load of database routines grouping >> methods into easy to use objects. All the routines are currently MySQL >> based. My future plans are to have MSSQL, SQLite and maybe PostgreSQL as >> database options. >> > > > Out of curiosity, what's your goal with this? > > There's no shame in picking one technology and sticking with it, to > the exclusion of others: you can simplify your codebase, reduce > maintenance effort, and generally get on with life in other areas. >
My software ends up on a wide variety of hosts, Linux, BSD, Windoze, you name it. A lot of my customers are on shared hosting where they generally aren't in a position to add new perl modules or server features. Some of the Windoze shared hosting will only have MSSQL available, so I'm missing out on them (although they don't always have perl available, or the Perl DBI and ODBC modules available). With large windoze customers on dedicated box's I get a lot of, "We want to keep all our databases on MSSQL", it can be hard enough to get them to put Perl on, forcing them to install MySQL just means more people drop off... SQLite... well I only read up on it recently and it looks like fun :) Although the thought of having to re-write whole tables and move the data across to remove a column doesn't :\ > If your goal is to produce a generally accessible library that's > DB-agnostic, that's a noble goal, but usually quite aside from a > typical business objective. > Hmm... I remember I did write a module a few years ago that took the MySQL create tables SQL and turned into MSSQL create tables syntax, but I'm not sure if that's the way forward... If you've read our (my) projects page you'll notice "Portable module collection", I'd be temped to make some pure Perl database modules people could use... By the way if anyone has a project idea you think would be good for us to do as a group then please put your suggestions forward and I'll put them on the projects page. Although I'm not sure what namespace these modules would go in as Adam Kennedy has plans for the "Portable:: namespace... David Cantrell wrote: > <delurk> hi, my name's Dave and I'm one of the London.pm cabal </> Ahh... part of the "evil uber-geek cabal" as Jonathan Stowe recently put it. I'm Lyle the "Athleek" (I know you've been waiting of me to say that Dave) who's been spending about 3 hours a day working on and promoting this group. > Class::DBI or DBIx::Class. Personally I prefer Class::DBI but its > internals are nasty and DBIx::Class seems to have more active... Interesting. But for my purposes I generally try to stick to pure Perl modules so that I can guarantee that my shared hosting customers can use my scripts (just uploading additional modules by FTP). Obviously I try to code my stuff to see if any faster XS libraries are already available before using the pure Perl ones. Strangely enough that brings me on to the CPAN dependencies lookup feature... Can't for the life of me remember who maintains that :P It would be REALLY useful if it showed which dependencies were pure Perl and which used XS and alike. Would certainly save me a lot of time tracking down a modules dependencies to see if it's all pure Perl and suits my purposes ;) >> I'm guessing the syntax for creating tables, etc, will be different for >> each. >> > > Neither of the modules helps with that anyway, although the syntax > should be mostly the same - CREATE TABLE is defined as part of the SQL > standard. Where you'll find differences are in some of the extended > datatypes (PostgreSQL is a particular offender here) which aren't > supported everywhere, and in the non-standard methods that all databases > use for doing things like telling the storage engine where to put the > data and (in some cases) what format to use (eg MyISAM vs InnoDB for > MySQL). > Hmmm... so maybe my old module would be worth maintaining... Mark Hughes wrote: > <delurk2> I'm Mark, and actually work in Bristol - though am familiar > with many of this London.pm cabal through lurking on their list > (though to be fair I was living in the smoke at the time) </delurk2> > Hi Mark, welcome to the list. I hope you can make it to our first meet :) > We've been using Class::DBI on our application for the last 4 years or > so and it's a joy to write code without worrying about the underlying > SQL. Some of the changes broke our (admittedly, rather specialised) > app so we've stuck with Class::DBI::Frozen::301 from 2005. > > If I was starting again I'd take a serious look at DBIx::Class and > Rose-DB as well. As Dave says, both are far more actively developed > than Class::DBI . > From having a quick look it seems like I'd prefer Class::DBI as the only dependency I've noticed so far that isn't pure Perl is Clone.pm, and I know there is a pure Perl clone so I might be able to mod it to be pure Perl... Lyle _______________________________________________ BristolBathPM mailing list [email protected] http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
