Database Abstraction Layer

[darkpaper]

All,
My company is considering SugarCRM for implementation.
Unfortunately we can't use MySQL as we don't have the manpower to support it.
Since v5.0 is GPL, would the main release developers adopt a Database Abstraction Layer design to make it easy to plug in different database backends such as PostgreSQL or Oracle?
The current db access method is very distributed and hard to port.
My development team can implement a functional astraction model, but need to know if it will be accepted or will our time be wasted.
We don't want to fork a good project.

Please respond.
Thanks,
Angel

[eggsurplus]

It would take more man power to develop something than it is to take the 15 minutes to set up MySQL and the 1 hr to set up periodic MySQL backups. There's really nothing else to maintain.

[andydreisch]

Hi darkpaper, eggsurplus is right. If your primary goal is to get Sugar up and running so your business can benefit from its use, then going plain jane MySQL is the easiest route. Absolutely.

Note that our Sugar Enterprise edition does support Oracle. We don't support PostgreSQL as yet.

Andy

[andydreisch]

Also, I'm moving this thread out to General Discussion as it doesn't directly pertain to Release 5.0.

Andy

[darkpaper]

The goal isn't to get the system up and running the fastest.
The goal is to give SugarCRM users a choice of databases.
Although the current design allows the use of oracle in the comercial releases, the way it is implemented, if it can be gathered by how the community version looks, does not allow for functional abstraction of database functions.
What about the people who want to use the community version and also use Oracle or Postgres?
Working around the limitations of MySQL is not as optimal as having real multidatabase support that's consistent in function.

Regards,
Angel

[andydreisch]

OK, darkpaper, I must have misinterpreted this then: "My company is considering SugarCRM for implementation".

In any event, requests for PostgreSQL support occasionally comes up but we haven't heard a steady stream of requests for this. As for Oracle, I must tell you that I don't recall a single request for Oracle support in the Community Edition. It's possible that there have been but I just don't recall.

I'll leave it to the others to comment on this thread. We'll be paying attention to the feedback.

Andy

[Deuce]

Until all the "if $db_type == 'mysql'" type code that is littered throughout just about every php file is gone and replaced with a call to a function in the abstraction layer porting to a different database will be difficult at best, and just about impossible to maintain. I did a Postgres port, so I've been there. I really, really think it would benefit SugarCRM in the long run to make an effort to clean up the database abstraction layer. It would reduce the bugcount, make database related problems/bugs easier to find, greatly reduce the size of many of the php files, and, I believe, would open Sugar to a bigger market.
MySQL may be fine for most, but it does have problems in some areas.
Others may need to integrate SugarCRM with other backends, and having the option of running it on whichever db engine I please would make life much easier.

[darkpaper]

Deuce,
That is exactly what I'm proposing. I see it as increasing stability.
If I can get developer buy-in to know that my time will not be wasted, I can start patching code.
It would not have to be an all or nothing thing, as current implementation methods can in theory coexist with an abstraction layer as long as new development on already converted code uses the abstraction methodology.

Regards,
Angel

[andydreisch]

Let me bounce this idea inside the halls here at Sugar.

The core nature of a change like this can make incorporating changes difficult and that it may make the most sense for Sugar to do it. I'm not sure but that's what I suspect will be the case. If I'm right then we'll have to weigh this agains the zillion other priorities.

Andy

[Deuce]

Thanks Andy. Getting rid of all the checks for db_type strewn all over the place would go a looong way towards at least a nice code cleanup.