when I create h2 memory database with a "name", I can't seem to use the name to refer to the table and keep getting "schema not found". Any idea?
val con = DriverManager.getConnection("jdbc:h2:mem:mytest;MODE=MYSQL;DATABASE_TO_UPPER=false;DB_CLOSE_DELAY=-1")
val stm = con.createStatement
val sql: String =
"""
|create table mytest.test_table1(ID INT PRIMARY KEY,NAME VARCHAR(500));
|insert into mytest.test_table1 values (1,'A');""".stripMargin
stm.execute(sql).result
```
Exception in thread "main" org.h2.jdbc.JdbcSQLSyntaxErrorException: Schema "mytest" not found; SQL statement:
create table mytest.test_table1(ID INT PRIMARY KEY,NAME VARCHAR(500));
insert into mytest.test_table1 values (1,'A'); [90079-199]
;MODE=MYSQL;DATABASE_TO_UPPER=FALSE is only suitable for H2 1.4.197 and older versions. For H2 1.4.198 Beta and newer versions you need to use MODE=MySQL;DATABASE_TO_LOWER=TRUE instead, otherwise all identifiers will be case sensitive, unlike in MySQL.
Database name is not related to the schema name in H2. By default, there is only PUBLIC schema for your tables. If you need a different schema, you need to create it first with standard CREATE SCHEMA mytest; command.
Please also note that H2 1.4.199 is an old unsupported version of H2 database.
Related
I have an Oracle database that is currently being migrated to an AWS Aurora Postgres database. As part of this I have had to update some of the datatypes in our sql files for creating tables e.g. changing NUMBER to NUMERIC etc. It has been going well but I am now coming across the following error when trying to insert some data into a table using spring data/JPA
ERROR: column "some_table_column" is of type numeric but expression is of type boolean
I can identify the issue is probably that the java class defines this column like
#Column(name = "SOME_TABLE_COLUMN", nullable = false)
private boolean someTableColumn;
while the sql file defines it like
CREATE TABLE MY_TABLE
(
SOME_TABLE_COLUMN NUMERIC(1) DEFAULT 0 NOT NULL,
etc..
Don't ask why it has been defined like this, I didn't write this code, I've just inherited it. But this has not been an issue ever with the Oracle database, and I'm only seeing the error now when running against Postgres. Does Oracle do some sort of implict conversion behind the scene that Postgres doesn't do? Is there a way I can resolve this without having to migrate the column to a boolean datatype?
I am using oracle_fdw 2.2.0devel, PostgreSQL 10.13, Oracle client 18.3.0.0.0
We have a foreign table in Postgres defined as this:
CREATE FOREIGN TABLE public.tickers
(
ticker_id INTEGER,
ticker VARCHAR,
)
SERVER oracle
OPTIONS (table 'TICKERS', schema 'COMMENTARY', readonly 'true');
This is connecting to as 12c SE database. This works fine, however, I've noticed that the query in Oracle is actually looking like this:
SELECT
/*618157932326e692807010156f98ddac*/
r2."TICKER_ID",
r2."TICKER"
FROM "COMMENTARY"."TICKERS" r2
WHERE (upper(r2."TICKER") = upper(:p1))
Why would it automatically be adding the "UPPER" clause? This slows the Oracle query and does not use an index, unless I create a FBI using "upper".
Was wondering if there was some option I'm supposed to disable.......
The only way that oracle_fdw will generate an Oracle query that uses the upper function is if the original PostgreSQL query already had upper in it.
I am trying to use sqlalchemy to create a schema in postgres. I cannot find a working example of the method of creating the schema via the MetaData and reflect function where one declares the name of the schema.
conn = db.postgres_db(host, port, database, pass, user)
postg_meta = sql.MetaData(bind=conn.engine)
postg_meta.reflect(schema='transactions')
stat_query = sql.select([sql.distinct(acocunts.c.user_id)]
This is a snippet of the code given to me and I am attempting to clarify where and how the schema ('transactions') is defined. I am new to sqlalchemy and the rational of some of its working pieces so I would appreciate some assistance.
Could this refer to a file with an external class where the schema is defined?
Thanks.
Postgres has the concept of a schema which is hierarchically ordered between the database and table like database.schema.table.
SQLAlchemy supports this concept of schemas for Postgres and other databases.
Since you performing a reflection, it is implicit that this schema already exists in your database. This is what the schema keyword is referring to.
You can confirm that this is the case by listing all the schemas in your database:
select schema_name
from information_schema.schemata
I'm following the sqlalchemy documentation for reflecting database tables using automap: http://docs.sqlalchemy.org/en/latest/orm/extensions/automap.html#generating-mappings-from-an-existing-metadata.
When I don't specific a schema, and Postgres uses the default public schema, this works as expected, and I find the names of my tables:
>>> m = MetaData()
>>> b = automap_base(bind=engine, metadata=m)
>>> b.prepare(engine, reflect=True)
>>> b.classes.keys()
['ads', 'spatial_ref_sys', 'income']
But when I specific an explicit schema, I don't have access to the tables in Base.classes anymore.
>>> m = MetaData(schema='geography')
>>> b = automap_base(bind=engine, metadata=m)
>>> b.prepare(engine, reflect=True)
>>> b.classes.keys()
[]
The MetaData reflected correctly though:
>>> b.metadata.tables
immutabledict({geography.usa_cbsa_centroids': Table('usa_cbsa_centroids', MetaData(bind=Engine(postgresql://asteroids:***#localhost:5432/asteroids)), Column('GEOID', VARCHAR(length=5), table=<u
sa_cbsa_centroids>, nullable=False), ...})
Note that the tables and columns are only known at runtime.
The answer is that database tables in SQLAlchemy require a primary key, and my table didn't have one. There is additional information on this page: http://docs.sqlalchemy.org/en/latest/faq/ormconfiguration.html#how-do-i-map-a-table-that-has-no-primary-key.
The SQLAlchemy ORM, in order to map to a particular table, needs there
to be at least one column denoted as a primary key column;
multiple-column, i.e. composite, primary keys are of course entirely
feasible as well. These columns do not need to be actually known to
the database as primary key columns, though it’s a good idea that they
are. It’s only necessary that the columns behave as a primary key
does, e.g. as a unique and not nullable identifier for a row.
Thanks to Michael Bayer for answering this on the sqlalchemy mailing list: https://groups.google.com/forum/#!topic/sqlalchemy/8F2tPkpR4bE
Here is some SQL for PostgreSQL (I know it's a silly query; I've boiled the original query down to the simplest broken code):
CREATE TABLE entity (
id SERIAL PRIMARY KEY
);
WITH new_entity
AS (INSERT INTO entity DEFAULT VALUES
RETURNING id
)
SELECT id FROM new_entity;
Here it is running on PostgreSQL 9.1:
psql:../sandbox/test.sql:3: NOTICE: CREATE TABLE will create implicit sequence "entity_id_seq" for serial column "entity.id"
psql:../sandbox/test.sql:3: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "entity_pkey" for table "entity"
CREATE TABLE
id
----
1
(1 row)
Here it is not running on PostgreSQL 8.4:
psql:../sandbox/test.sql:3: NOTICE: CREATE TABLE will create implicit sequence "entity_id_seq" for serial column "entity.id"
psql:../sandbox/test.sql:3: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "entity_pkey" for table "entity"
CREATE TABLE
psql:../sandbox/test.sql:9: ERROR: syntax error at or near "INSERT"
LINE 2: AS (INSERT INTO entity DEFAULT VALUES
Obviously, the table creation goes fine in both cases, but it wipes out on the second query in PostgreSQL 8.4. From this error message I am unable to gather exactly what the problem is. I don't know what it is that 9.1 has and 8.4 doesn't have that could result in this syntax error. It's hilariously hard to google it. I am approaching the level of desperation required to trawl through the pages of PostgreSQL release notes between 8.4 and 9.1 and finding out if anything related to WITH … AS or INSERT … RETURNING was changed or added, but before I go there I am hoping one of you has the experience and/or godly google-fu to help me out here.
Data-modifying statements in WITH were introduced in Postgres 9.1