22 replies to this topic

[mikef]

I think there are real gains to be had from supporting PHP 5 only and dropping PHP 4, so would support that choice.
I don't know if there are any similar gains in MySQL 5 though, so don't see a reason for dropping MySQL 4 at this stage.

[Jim Browski]

Ralph, on Jul 19 2007, 12:09 AM, said:

I don't think you'll see the need for MySQL 5 only applications for a while - at least not from the Etomite project...

But maybe mySQL4 will soon go the way PHP4 is going today ...
... but hey, if you don't need the bells and whistles that mySQL5 offers and rely on standard SQL for cocoon i also don't see the need for a mySQL5-only version.
Maybe there is a chance to implement an abstraction layer to support other database engines like postgreSQL instead.

But maybe ... I'm just a "latest feature" junkie ...

[Ralph]

Jim Browski, on Jul 18 2007, 06:24 PM, said:

Maybe there is a chance to implement an abstraction layer to support other database engines like postgreSQL instead.

I have been doing a lot of research on the pro's and con's of writing applications which take advantage of database abstraction layers which support multiple database engines and the opinions are varied... What I have come to conclude, however, is that there is a definite cost in performance and maintainability when it comes to providing such features... And considering how Etomite has been admired for its overall speed in rendering pages I surely wouldn't want to sacrifice any significant amount of speed just to be able to say that the software supports additional database engines...

I'm sure that once Randy reads this post he will have some practical input to add into this discussion...

My stance, for the time being, is that supporting only MySQL is the best course of action - at least for the immediate future... That isn't to say that we couldn't add support in later... But if you take the time to read up on the concept, adding in support down the road can be a logistical nightmare because virtually every query within the entire code base will need to be examined under a magnifying glass in order to assure that they will work properly with all supported database engines... This complexity can extend right to the design of the data model itself - the core of the entire application...

The crux of the overall concept is that, for example, you wouldn't write an application for an IBM mainframe computer with the idea that you might port it over to run on a Linux server farm, an XBox, or an iPhone at some point... Too radical of a comparison...??? Not really... Extra...!!! Extra...!!! Read all about it...!!!