User tests: Successful: Unsuccessful:
Pull Request for Issue #20272
ext/pgsql
In an environment with PostgreSQL database support, make sure PHP has PDO support enabled with the PostgreSQL engine available (if you can already run native ext/pgsql
then you should only need to enable the PDO support if it's not there already). Validate Joomla functions on-par when running PDO PostgreSQL as it relates to the native PostgreSQL driver.
Update 4.0 compatibility references.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_admin com_config Language & Strings Installation Libraries Postgresql |
Labels |
Added:
?
?
|
Smart Search Batch Index Button breaks, because com_finder adds serialized PHP objects to the DB which include null bytes. It "worked" in postgresql because that silently truncated null bytes, under PDO it breaks. Proposed solution: run base64 on it
And that becomes problematic without introducing driver specific behavior since these serializations are stored to the database. Maybe for 4.0 we can have a hard "changed serialization/encoding format" break in the data structure and force sites to have their search index to be rebuilt, but I don't think that's a fair requirement for a 3.x release. Be it implementing Serializable
and cleaning up how the FinderIndexerResult
object is actually serialized or adding a base64 wrapper, we should do something.
It actually also complicates moving from native PostgreSQL to PDO because you'd get bitten by this driver specific switch anyway.
Can't say I'm a fan of trying to code a mitigation layer in, to me there isn't a "good" option here that doesn't expose some kind of B/C or migration issue.
force sites to have their search index to be rebuilt, but I don't think that's a fair requirement for a 3.x release.
Do we actually need to do this? A transparent "does a plain unserialize work? No, then try a base64 decode first" should do the job withouth rebuilt, right?
It actually also complicates moving from native PostgreSQL to PDO because you'd get bitten by this driver specific switch anyway.
I disagree on that part: smart search is broken in both Postgres drivers right now, just nobody noticed.
Joomla does not support the escape function for binary data. It may be time to add it.
Example for postgresql (including PDO):
/**
* Quotes a binary string to database requirements for use in database queries.
*
* @param mixed $text A binary string to quote.
*
* @return string The binary quoted input string.
*
* @since __DEPLOY_VERSION__
*/
public function quoteBinary($text)
{
return 'E\'\\\\x' . bin2hex($text) . '\'';
}
More examples for other DB you can find on csthomas/joomla-cms@501b92a
a lot of changes have been happend in the meantime especially in the com_finder
so can we reconsider this one for 4.x?
PDO PostgreSQL is already in 4.0, and native PostgreSQL is already out.
The intent here was to make the PDO variant available for 3.x to simplify the migration path (being able to switch platforms pre-upgrade versus being unable to do an in-place upgrade because you won't have the same database driver options available on both ends of it).
This can slip to 3.10 if need be, but really we need to make sure that either the PDO option is in 3.x otherwise the 17 PostgreSQL users are going to come at us with pitchforks and chains.
understood, and sorry to be 1 of 17, but not in my plan to came back to you
with pitchforks and chains
my mostly feeling is to give up, right now
we deserve a mysql world only
starting with a fresh 3.9-dev with postgresql, and after install, applying this pr and then switch to PDO Postgresql via Global Configuration->Server
....... still testing, but till now not able to found big issues
so the question is :
it's all about this one 1d8a064#diff-7acfc2b93c1bae5b5114fc39c2c715ff ?
i think com_finder is not perfect even on mysql, so yes, i agree with you let's fix the installation for now ;)
Rebased the PR, tested installing again, works fine here. This is on a PHP 7.1 and PostgreSQL 10.0 build.
tested installing and works now, with PHP 7.2.7 and Postgresql 9.6.8
installing a multilanguage site fail with : There is no active transaction
the same message There is no active transaction
when you try to create a new category
i've made this pr mbabker#27 against your branch mbabker:pdo-pgsql
should fix the nested transaction issue (create/delete a category)
btw a multilanguage site even if it is installable now, still have multiple issues
Transaction fix merged, anyone aside from the two of us who can test and validate this thing?
Tested, works fine
Altered successfully Test by @SniperSister at Issue Tracker.
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-08-07 09:05:12 |
Closed_By | ⇒ | wilsonge |
Given the number of Postgres users we have is so low, with @SniperSister and @alikon 's tests I'm merging this
I have tested this item? unsuccessfully on 6de3bf5
* Creating a category throws a "There is no active transaction" exception, apparently being related because the "unlock" call (commiting a transaction) in TableNested is being made after the unlock has already being called in Table
Besides that: works great!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20386.