I am using the ZF + Doctrine 2.1 implementation by Ralph Schindler (https://github.com/ralphschindler/NOLASnowball/tree/doctrine2-managed-crud).
My MySQL database uses some reserved words, a column named order. I need to tell Doctrine to quote identifiers, but I can't seem to get it to work in the application itself nor in the scripts/doctrine.php (https://github.com/ralphschindler/NOLASnowball/blob/doctrine2-managed-crud/scripts/doctrine.php) to use the command line tool.
Note: I'm reverse engineering my database by using the command:
php scripts/doctrine.php orm:convert-mapping --from-database annotation library/app/Entity/
which gives the error:
Syntax error or access violation: 1064 You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version
for the right syntax to use near 'order' at line 1
because the column order doesn't get quoted with ticks.
I have finally found it.
It appears the NOLASnowBall demo app uses an older Doctrine than the current stable. With Doctrine 2.1.4 the ticks are added, without the need to set the extra option.
I have updated Doctrine and took the new Bisna library from Guilherme Blanco's repository at https://github.com/guilhermeblanco/ZendFramework1-Doctrine2
Related
I have this issue related to the pages search, on the admin side of wagtail. This is the Django Error:
ProgrammingError at /admin/pages/search/
function ts_rank(unknown, text, tsquery) does not exist
LINE 1: ...ry"."body") ## (to_tsquery('''irp''')) ORDER BY ((ts_rank('{...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
When i debug the wagtail code, the pages query result returns this:
Unable to get repr for <class 'wagtail.search.backends.database.postgres.postgres.PostgresSearchResults'>
After looking at wagtail 4 documentation, there's no info about the postgres search engine. Only in documentation up to 2.15 version. And this:
WAGTAILSEARCH_BACKENDS = {
"default": {
"BACKEND": "wagtail.search.backends.database",
}
}
...should work with Postrgres from then on.
The data base was originally in SQLite and then i migrated to Postgres with pgloader
Is there any configuration/upgrade I missed to make wagtails admin search work with postgres? Can the problem be an error caused by the migration?
After talking with Wagtail Support via Slack they've told me that the error is caused by the pgloader migration. Since it was a small project on-develpoment project i decided to rerun the migrations in a new database but it's not the best solution if you have lots of data already.
I try to start MassTransit/Sample-JobConsumer on EntityFramework Core, but having strange error
(0x80131904): Incorrect syntax near the keyword 'UPDATE'
Steps to reproduce:
Clone MassTransit/Sample-JobConsumer
Remove PostgreSQL an install EntityFrameworkCore
Command Update-Database creates a correct database
Start project JobService.Service
Post request from Postman (response is valid):
RabbitMQ accept requests:
But error occured during processing (in console):
Please, anyone help me to understand what is happened.
You can see repository on github with EntityFrameworkCore storage implemented
P.S. With default configuration the error was different
[Update 1]
After I changed PostgresLockStatementProvider to SqlServerLockStatementProvider (Thanks to Chris Patterson for help). But I`ve got another error:
[Update 2]
After I was installed plugin for RabbitMQ everything became works fine with EntityFrameworkCore too! (Thanks to Chris Patterson)
To change to SQL Server, you'd need to change the EF Core configuration to UseSqlServer, you also need to remove the PostgreSQL lock provider (the default lock provider is SqlServer). There are three lines where this change is needed, one for each state machine.
Using the jdbc4.2 implementation contained in postgresql-9.4.1212.jar, I generate an error when calling the java.Sql.Connection isValid() method on a connection to a postgresql 9.3 database (java8 and postgres both running on windows 7).
The path to producing the error is complicated but reproducible (will provide relevant code shortly) and involves a sequence of sql calls on a single db connection whose default schema is reconfigured prior to each use via an explicit execution of SET SEARCH_PATH='[some schema]'.
I find that the error occurs if and only if I render the SEARCH_PATH keyword using upper case (that is, the error does not occur if I execute SET search_path='[some schema]' - only when I execute SET SEARCH_PATH='[some schema]').
Note that the direct effect of executing either variant is the same -- in both cases the default schema associated with the connection is changed to [some schema]. It's just that, eventually, a downstream call to java.sql.connection.isValid() causes the database to crash if I've used SEARCH_PATH instead of search_path.
I can see that the jdbc driver's implementation of java.sql.connection.setSchema() uses the lower-case variant; something that makes me think this apparent case-sensitivity may be a known issue, but I have found no mentions of it anywhere online.
Note that the problem does not occur if I either: (1) use an older jdbc driver (postgresql-9.3.1100.jdbc4.1.jar) with my 9.3 database, or (2) use the latest jdbc driver with a postgresql 9.6 database.
I'm wondering if anyone has run into this specific problem, and also, if there are other known incompatibilities b/w the 9.3 database and the latest jdbc driver.
The driver is failing to invalidate the prepared statement cache because it only detects SET search_path=... when the config parameter is lower case.
See line 2056 of this commit.
I can't find an issue that describes this. Please have a look yourself and raise one if needed.
I'm finding references in the 9.5 manual to phraseto_tsquery
https://postgrespro.com/docs/postgrespro/9.5/textsearch-controls
But if I use it in my query it gives me this error:
No function matches the given name and argument types.
SELECT phraseto_tsquery('english', 'The Fat Rats');
Was this function not added with 9.5 as intended or is it likely there's some other problem on my side. Running 9.5.4 of the database currently. Anyone that can confirm?
For anyone looking; took the step to install postgresql 9.6beta4 and I'm no longer receiving the error message. In other words phraseto_tsquery seems to only be fully supporting in the current 9.6 beta and upcoming full release.
As noted here I'm trying to use the PostgreSQL COPY ERROR_LOGGING, ERROR_LOGGING_SKIP_BAD_ROWS options.
My SQL looks like this:
COPY users FROM 'C:\Users\admin\osmosis_temp\users.txt'
(ERROR_LOGGING, ERROR_LOGGING_SKIP_BAD_ROWS);
I get an SQL output of ERROR: option "error_logging" not recognized. Am I missing something that turns on the error logging in the first place?
PostgreSQL 9.3
At the top of the wiki page you've linked to one reads:
Error logging in COPY was a proposed feature developed by Aster Data against the PostgreSQL 9.0 code base. It was submitted and reviewed (1) but not accepted into the core product for that or any other version so far.
So that was only a concept.