I received the following error after upgrading my application to Rails 5 and it is somewhat cryptic:
...connection_specification.rb:170:in `spec': database configuration does not specify adapter (ActiveRecord::AdapterNotSpecified)
I found the solution to this problem, it turns out that in my case since I was connecting to multiple databases that there was a subtle change in what Rails 5 expected over Rails 4.
If you are connecting to multiple databases the establish_connection used within the model connecting to the separate database requires a symbol instead of a string in Rails 5.
Works
establish_connection :secondary_database
Where as the following no longer works:
establish_connection "secondary_database"
In my case some of my old database connections had used the string argument and were failing, causing me to think that there was an strange incompatibility between Rails 5 and my code base. I thought I would share this as I do not see it documented anywhere specifically.
Related
I am running into a very strange issue with Spring Boot and Spring Data: after I manually close a connection, the formerly working application seems to "forget" which schema it's using and complains about missing relations.
Here's the code snippet in question:
try (Connection connection = this.dataSource.getConnection()) {
ScriptUtils.executeSqlScript(connection, new ClassPathResource("/script.sql"));
}
This code works fine, but after it executes, the application immediately starts throwing errors like the following:
org.postgresql.util.PSQLException: ERROR: relation "some_table" does not exist
Prior to executing the code above, the application works fine (including referencing the table it later complains about). If I remove the try-resource block, and do not close the Connection, everything also works fine, except that I've now created a resource leak. I have also tried explicitly setting the default schema (public) in the following ways:
In the JDBC URL with the currentSchema parameter
With the the spring.datasource.hikari.schema parameter
With the spring.datasource.jpa.properties.hibernate.default_schema property
The last does alleviate the issue with respect to Hibernate managed classes, but the issue persists with native queries. I could, of course, make the schema explicit in those queries, but that doesn't seem to address the root issue. Why would closing a connection trigger this behavior?
My environment:
Spring Boot 2.5.1
PostgreSQL 12.7
Thanks to several users above who immediately saw what I did not. The script, adapted from an older pg_dump run, was indeed mucking with the search_path:
SELECT pg_catalog.set_config('search_path', '', false);
Removing that line, and some other unnecessary ones, resolved the problem. Big duh on my part.
In the PostgreSQL documentation https://www.postgresql.org/docs/10/libpq-connect.html, it has been said that multiple hosts can be specified in a single connection string such that all the hosts will be tried in order one after the other until one of the server gets succeeds.
But when i tried to implement the same setting in the tag present in my ASP.net web.config file, it is throwing error as no such host name. I am using NpgSQL provider in order to connect to PostgreSQL database.
I need to add multiple server names in the connection string such that if the server#1 fails then it should try for the next server server#2 immediately provided in the order until it succeeds
Can you please suggest on how multiple hosts can be provided in the connection string?
The Npgsql driver does not currently support this functionality. The issue tracking this is https://github.com/npgsql/npgsql/issues/732, I'm still hoping we can get this into the next release but there's a lot going on.
Load balancing and failover is avaialble in Npgsql version 6. At the time of writing v.6 is in preview.
Simple failover example (server2 is only used if a connection could not be established to server1):
Host=server1,server2;Username=test;Password=test
Example with load balancing (round robin I guess):
Host=server1,server2,server3,server4,server5;Username=test;Password=test;Load
Balance Hosts=true;Target Session Attributes=prefer-standby
https://www.npgsql.org/doc/failover-and-load-balancing.html
I have deployed various versions of the app previously with no errors.
However, I had to make some modifications on two tables in my AWS RDS running PostgreSQL. alter table NAME alter column NAME type date using to_date(...)
I've done that directly on the AWS RDS and modified SQLAlchemy column accordingly. date = Column(Date)
Any API call that sends queries these two tables returns Internal Server Error - In the meantime, there are no errors in deploying this version of the app and moreover from my python interpreter running any SQLAlchemy code that queries any of these two tables always returns what's expected.
I have tried several ways to fix this. The only one that worked is to remove the line date = Column(Date) from SQLAlchemy setup file - Then there was no 500 on any API call but of course that doesn't help as I need that column!
Any help on this will be highly appreciated really...
i am doing a simple select using the zend\db\sql classes and i got the following error.
Notice: Attempting to quote a value in Zend\Db\Adapter\Platform\Mysql
without extension/driver support can introduce security
vulnerabilities in a production environment. in
C:\wamp\vendor\zendframework\zend-db\Zend\Db\Adapter\Platform\Mysql.php
on line 134
Below is my code that output the errors.
$select2 = $this->sql->select()
->from('users')
->where(array("fbid = ?" => $id));
$selectSqlString = $this->sql->getSqlStringForSqlObject($select2);
$this->dbo->query($selectSqlString, Adapter::QUERY_MODE_EXECUTE);
May i know why does this happens and what should i do to prevent it?
Cheers~
By looking at the code for the MySQL class (I know that the provided link is for ZF2, but it looks like the same code is used), it would seem, that you are missing both the PDO and mysqli extension. That would mean that you are currently using mysql extension to connect to MySQL db, which is deprecated.
As a solution, I would recommend installing mysqli.
When on my dev machine, all works perfectly. Even using production connection values (so even when I connect to production from the dev machine). I don't think it's a permission problem because I am using the same credentials, just using EF5 instead of linq2sql, as the previous version of the service that worked. Also, the sql-profiler does not show a failed login attempt.
Connection string is:
Data Source=MYSQLSERVER;Database=MYDB;Integrated Security=True;
The error is:
Invalid value for key 'attachdbfilename'.
I have logged the connection string being passed into the dbContext code:
Database.Connection.ConnectionString = settings.DbConnectionHourly;
This is a class that inherits from my real dbContext (which packaged in a dll) and the settings get injected. Again, this works in Dev but not in production (server 2008 r2, IIS 7.5, framework.4).
Turns out that entity framework was trying to be very smart, but it was giving a very un-smart error message. So by convention, if you don't pass the context name in as a constructor, entity framework will assume the classname as the name of the connection string. What it will also do (which I was unaware of), is in development it will automatically connect to and create a schema using the visual studio built in sqlExpress. So in development, everything worked because this 'automagic' creation succeeded and since I later changed the connection to a different database, I was none the wiser about what EF was doing under the covers (EF was doing the wrong things but the end result worked).
However, when the application went to production, there is no sqlexpress or any database on the webserver so the automagic connection/creation sequence failed. Now if the error message had any useful information in it, this would be obvious. But since I had never set an 'attachdbfilename', nor did it tell me what the value of 'attachdbfilename' was or any context or what it was trying to do, this made figuring this out that much more challenging.
The fix was simple:
public HourlyContext(ISettingsWrapper settings)
: base(settings.DbConnectionHourly)
{ }
Instead of setting the connection after the context gets created (the creation process will immediately try to work it's magic with it's built in conventions/defaults), I now set it immediately through the constructor.