database backend?
Submitted by cperg on Thu, 06/05/2014 - 23:36
Forums:
We are a Drupal/PostgreSQL shop. There is a module that was written to integrate this project into Drupal. It seems to be just grand for MySQL and I have been looking at that project but have continued to be thwarted in writing a patch for it.
It occurred to me earlier that perhaps the core project might not be compatible with PostgreSQL. If that is the case then nothing I could do for the existing module would work.
My question... Where would I go to see if this project supports PostgreSQL? or Does anyone have a quick answer?
icc
Thu, 07/03/2014 - 12:28
Permalink
We would love for our system
We would love for our system to work with PostgreSQL as well. Variables has been written in camelCase to adhere with Drupal's OO best practices, which has lead to this module not working with PostgreSQL.
If or when (probably inevitable in most development) a restructuring or rewrite of the core happens this will be taken into consideration.
The issue may be followed up here: https://www.drupal.org/node/2261293
cperg
Fri, 07/04/2014 - 02:59
Permalink
perhaps there has beena misread of the standards
The file names in the database are lower cased not camel cased. This is in alignment with the Drupal standards. However when you make your request to the database as a query you are overwriting that standard with AS statements that return camel cased results for one database type and not for the others (as the standards for other databases are not completely compatible). Perhaps there is some distinction between a variable and a subscript? In most cases a subscript is directly related to the field name in the database when it is associated with a database query.
icc
Mon, 07/07/2014 - 16:22
Permalink
You' are right
and I agree, gaining camelCase array keys shouldn't be done this way.
I really wish Drupal had a better database abstraction layer to avoid mistakes like this one. Something like activerecord.
cperg
Mon, 07/07/2014 - 18:17
Permalink
Is there anything I could do assist?
thanks for reviewing the event.
cperg
Mon, 07/07/2014 - 19:57
Permalink
here is an altered h5p.class.inc
Rather than tackle the entire code set I did a workaround as a test. It works up to a point. Somehow the imports of the existing upload-able libraries work but the running of the libraries fail. It may have to do with the manner in which the those libraries are stored. I have not been able to get to that issue.
The attached file was named 'h5p.classes.inc' - I renamed it as 'h5p.classes.inc.h5p' - It is a copy of the same file from the module installation. After testing for pgsql database I took the resulting array from each of the two queries and then moved them to a temporary array where the subscripts were renamed according to the camel back for the rest of the code. This most likely would be considered a hack not a solution but it does allow us to upload the h5p libraries even though they do not run properly.
I hope this approach helps in some way. I am available for testing against a PostgreSQL database.
icc
Fri, 07/18/2014 - 11:41
Permalink
Thank you for contributing
Thank you for contributing.
I did some re-factoring to try and create a solution which will be easy to use for other content management systems as well. The code has been commit-ed to the 7.x-1.x branch and will be part of the next Drupal 7 release.
Feel free to check out the code and test it. It seems to work well on my Drupal 7 with postgresql.