On Tue, Sep 02, 2014 at 02:02:39PM -0400, Ron W wrote: > On Tue, Sep 2, 2014 at 10:18 AM, <sky5w...@gmail.com> wrote: > > > Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB > > here)? > > > > I think that the only way this will happen would be to fork Fossil into a > new project. This would be because of the overall underlying goals of the > Fossil project vs a "Fossil-saurus" project. > > As I understand it, Fossil is intentionally designed around the feature set > provided by SQLite. Therefore, to support DB back-ends other than SQLite > would not just require rewriting SQL queries, but significant re-working of > Fossil's C implementation.
I'm probably out of my area but it would seem writing a wrapper to transform the database calls to $BACKEND_OF_CHOICE would be in order unless sqlite does stuff that is really not appropriate for other databases and cannot readily be transformed to make sense with other databases. "Theoretically" it should be possible to do that without changing the API calls at all. You would "just" link the wrapper instead of sqlite. If you can get this to work it's obviously the safest, most low-impact way to do a major change like that while not breaking what already works. I have done stuff like this on another platform but am not familiar with any of the parts here i.e. I have no knowledge of C, fossil, etc. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary / \ http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
