Hi,

I am also interested in getting PostgreSQL support implemented into Piwigo.

I don't have much PHP-coding experience, but I am able to assist in testing, SQL-writing and am willing to commit to this for a long time if others can commit as well.

I am currently using Gallery 2.3.2 as version 3.x has dropped support.

Kind regards,

Joost

Nicolas,

Feel free to email me directly (Please let me know if you can access my email-address on here) when you get to the stage I can help with testing.

Kind regards,

Joost Roeleveld

nicolas wrote:

J. Roeleveld wrote:

Nicolas,

Feel free to email me directly (Please let me know if you can access my email-address on here) when you get to the stage I can help with testing.

Kind regards,

Joost Roeleveld

Yes I see your email. I will let you know. code will be on github but nothing interesting for now.

Ok, thank you.
(Forgot I had an account here already ;) )

I don't understand... why not switch database backend to abstract layer like PDO? That way user is free too choose whatever database engine he wants to use whether is is Postgree, SQLite or MSSQL...

It has already been said : all engines are not equivalents
We use ON DUPLICATE KEY UPDATE and SQL_CALC_FOUND_ROWS which only exist on MySQL

Even with PDO, it won't work with other engines

nicolas wrote:

mistic100 wrote:

It has already been said : all engines are not equivalents
We use ON DUPLICATE KEY UPDATE and SQL_CALC_FOUND_ROWS which only exist on MySQL

Or insert ignore. But using proprietary extensions in a first step and after saying it's not easy to make sql code for several database engine is a bit strange.

We can use these MySQL specific command because we have decided to focus on MySQL. It is more a consequence than a cause.

I don't think it's useful to have this debate one more time. The problems described on [Forum, post 124245 by plg in topic 18008] Support of Postgresql and SQLite in question are still here today.

I would even say that today, being compatible with other database engines has even "less" importance because MariaDB is a drop-in replacement of MySQL (and it works fine with Piwigo).

This is a remarkable discussion and might be seen as a very painful decision for many, especially if there was already some work done for abstraction. It is, however, a very good example for younger developers of the problems they will run into if they make wrong decisions too early, I will mark this thread as something to read for my students.

What is wrong, what is right?

It is not about the features of a product you are supporting compared to another product, in this case databases. It is about making a decision that enables or disables possibilities and options. In this case, the Piwigo team decided to not open the future development for other database options, maybe things that are not very clear to see right now. Instead they closed the door for many interesting developments by binding themselves to one single product, trapping exactly in that honeypot that database vendors are building just for you, the developer - use our special features, and never ever get your product away from us! An almost classic example of the dangers of wrong decisions.

Of course, the wrong decision has been made a long time ago, when piwigo started with the limited "LAMP" mindset we know from many early days web developers - many people did it.

But many people have understood the problems of such a product and feature lock-in and invested in changing their application data storage layer into something product agnostic - in the long term a really good investment, because maybe in a few years you will be able to follow completely different data storage paradigms, especially if your application needs to scale or simply because the landscape changes. Examples: cloud storage - hey, would be nice to plugin some cloud storage provider, well, no way with a fixed storage layer. Scaling? Performance? Would like to use some distributed Key-Value store? CouchDB with mobile client sync?  No way, Piwigo developers to stay in the MySQL corner forever.

Of course it will never be easy to change the data storage layer of an application, but the longer you wait, the more problems you will have.

Of course Piwigo is still a nice product for your personal gallery, but then, of course, you will ask yourself: why do I need that complicated database at all, why can I not simply use a sqlite storage so I can copy the whole thing easily to my Raspi and have very easy backups?

You see, an option-cutting decision disables interesting developments in any direction, not only in the direction if getting bigger, but also in the opposite of getting smaller...

To answer the above question: following a way where you have no options anymore is always a wrong decision.If in doubt, do the right thing and keep as many options as possible.

My point of view. More database support would help PWG popularity.
Having a great database abstraction layer would make it easier plugins.
It would avoid dirty unsecured SQL query in plugins.
It would allow to implement Memcached support as refer here, http://piwigo.org/forum/viewtopic.php?id=23162
Most Open Source web application support multiple database.

I also agree it is a very important change and it will require a lot of work and would break a lot of plugins.
Agree it will be complex but i do think it would help the project.

Even if some specific MySQL function does not exist, there is available workaround, not always easy but technically possible.
http://www.postgresql.org/message-id/27 … .gmail.com
http://www.postgresql.org/message-id/11 … lfix.co.uk

MySQL vs MariaDB is also a concern for the very long term.
https://mariadb.com/kb/en/mariadb/maria … atibility/

Other database could be only community support. There can be different model.
However a clean refresh might not be that bad.
Would be nice to consider it for a long run.