Doctrine 2 schema update produces MySQL errno 150, Foreign Key constraint - symfony

When using Doctrine ORM in Symfony2, I have the following tables generated from three different entities, of which accessory has two foreign key constraints (marked A and B below).
describe publication;
+-------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| kid | varchar(10) | NO | | NULL | |
| title | varchar(255) | NO | | NULL | |
| title_canonical | varchar(255) | NO | | NULL | | <- A
| created | datetime | NO | | NULL | |
| modified | datetime | NO | | NULL | |
+-------------------+--------------+------+-----+---------+----------------+
describe accessory;
+-------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| publication_title | varchar(255) | YES | | NULL | | <- A
| index_id | int(11) | NO | | NULL | |
| index_alias | varchar(255) | NO | | NULL | |
| value | longtext | NO | | NULL | |
| attribute_name | varchar(255) | YES | | NULL | | <- B
+-------------------+--------------+------+-----+---------+----------------+
describe attribute;
+-------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| name | varchar(255) | NO | | NULL | |
| name_canonical | varchar(255) | NO | | NULL | | <- B
| parameter | varchar(16) | NO | | NULL | |
+-------------------+--------------+------+-----+---------+----------------+
The foreign keys are mapped with annotations:
Publication.php
/**
* #ORM\OneToMany(targetEntity="Accessory", mappedBy="publication")
*/
protected $accessories;
Accessory.php
/**
* #ORM\ManyToOne(targetEntity="Publication", inversedBy="accessories")
* #ORM\JoinColumn(name="publication_title", referencedColumnName="title_canonical")
*/
protected $publication;
/**
* #ORM\ManyToOne(targetEntity="Attribute", inversedBy="accessories")
* #ORM\JoinColumn(name="attribute_name", referencedColumnName="name_canonical")
*/
protected $attribute;
Attribute.php
/**
* #ORM\OneToMany(targetEntity="Accessory", mappedBy="attribute")
*/
protected $accessories;
but upon running php app/console doctrine:schema:update --force I got this exception
[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE accessory ADD CONSTRAINT FK_A1B1251CCEE83EE7 FOREIGN KEY (publication_title) REFERENCES publication (title_canonical)':
SQLSTATE[HY000]: General error: 1005 Can't create table 'publicationsapp.#sql-2a3c_2828' (errno: 150)
So I ran php app/console doctrine:schema:update --dump-sql
ALTER TABLE accessory ADD CONSTRAINT FK_A1B1251CCEE83EE7 FOREIGN KEY (publication_title) REFERENCES publication (title_canonical);
ALTER TABLE accessory ADD CONSTRAINT FK_A1B1251C5CBDA8E FOREIGN KEY (attribute_name) REFERENCES attribute (name_canonical);
CREATE INDEX IDX_A1B1251CCEE83EE7 ON accessory (publication_title);
CREATE INDEX IDX_A1B1251C5CBDA8E ON accessory (attribute_name);
What's the correct way to resolve this? Should I edit the tables manually or with Doctrine?
Based on what I've read about errno 150, the foreign column needs to be indexed, but can't Doctrine handle this automatically?

One could add unique=true to both $nameCanonical and $titleCanonical properties or whichever columns are referenced by the foreign key. Then drop and run the schema update command to recreate the tables.
In the case of $titleCanonical
/**
* #var string
*
* #ORM\Column(name="title_canonical", type="string", length=255, unique=true)
*/
private $titleCanonical;
But ideally with Doctrine, the foreign keys should be referenced to the other table's primary key to make it valid.

Related

Undefined column: 7 ERROR: column ... of relation ... does not exist

A call to the following local endpoint:-
curl -k --location --request POST 'https://localhost:8443/project_exports' \
--header 'Authorization: Bearer eyJ0eXA...YVhA' \
--header 'Content-Type: application/json' \
--data-raw '{
"email": "bob#test.com",
"projectid": 0,
"status": true,
"emailedat": "2022-08-22T09:56:28.487Z",
"generatedat": "2022-08-22T09:56:28.487Z"
}'
returns an error like thus:-
"message": "An exception occurred while executing a query: SQLSTATE[42703]: Undefined column: 7 ERROR: column \"projectid\" of relation \"project_export\" does not exist\nLINE 1: INSERT INTO project_export (id, email, projectid, status, em...\n ^",
"code": 500
But the field exists in both entity and db:-
<?php
namespace App\Entity;
use ApiPlatform\Core\Annotation\ApiResource;
use App\Repository\ProjectExportRepository;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Serializer\Annotation\Groups;
/**
* #ORM\Entity(repositoryClass=ProjectExportRepository::class)
*/
#[ApiResource]
class ProjectExport
{
...
/**
* #ORM\Column(type="integer")
*/
#[Groups('entry-index')]
private $projectid;
...
mysql> describe project_export
-> ;
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| email | varchar(255) | NO | | NULL | |
| projectid | int | NO | | NULL | |
| status | tinyint(1) | NO | | NULL | |
| emailedat | datetime | NO | | NULL | |
| generatedat | datetime | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
6 rows in set (0.01 sec)
I'm serving the api from a docker instance locally. Not sure if this affects it any way?
So, why then, no data gets persisted and the error thrown?

MariaDB DATETIME Index not working with Between FROM_UNIXTIME()

I have a table with DATETIME field, which is indexed by a BTree. Now i want to query it with following statement:
SELECT
count(us.CITY) as metric,
us.CITY as Name,
us.LATITUDE as latitude,
us.LONGITUDE as longitude
FROM
FACT
LEFT JOIN
USER us
ON
us.ID_USER = FACT.USER
WHERE
ASSESSMENT_DATE BETWEEN FROM_UNIXTIME(1601568552) AND FROM_UNIXTIME(1604028277)
GROUP BY us.CITY, us.LATITUDE, us.LONGITUDE;
EXPLAIN:
+------+-------------+-------+--------+----------------------------+---------+---------+------------------------------+--------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+--------+----------------------------+---------+---------+------------------------------+--------+----------------------------------------------+
| 1 | SIMPLE | FACT | ALL | INDEX_FACT_ASSESSMENT_DATE | NULL | NULL | NULL | 762621 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | us | eq_ref | PRIMARY | PRIMARY | 46 | dwh0.FACT.USER,dwh0.FACT.ENV | 1 | |
+------+-------------+-------+--------+----------------------------+---------+---------+------------------------------+--------+----------------------------------------------+
2 rows in set (0.001 sec)
Interestingly, by only changing the dates manually into the DATETIME Format string it uses the index. But the FROM_UNIXTIME() function should in my opinion return the exactly same thing...
SELECT
count(us.CITY) as metric,
us.CITY as Name,
us.LATITUDE as latitude,
us.LONGITUDE as longitude
FROM
FACT
LEFT JOIN
USER us
ON
us.ENV = FACT.ENV AND us.ID_USER = FACT.USER
WHERE
-- ASSESSMENT_DATE BETWEEN FROM_UNIXTIME(1596649101) AND FROM_UNIXTIME(1599108827)
ASSESSMENT_DATE BETWEEN '2020-08-05 11:30:11.987' AND '2020-09-03 11:30:11.987'
GROUP BY us.CITY, us.LATITUDE, us.LONGITUDE;
EXPLAIN:
+------+-------------+-------+--------+----------------------------+----------------------------+---------+------------------------------+--------+--------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
|
+------+-------------+-------+--------+----------------------------+----------------------------+---------+------------------------------+--------+--------------------------------------------------------+
| 1 | SIMPLE | FACT | range | INDEX_FACT_ASSESSMENT_DATE | INDEX_FACT_ASSESSMENT_DATE | 5 | NULL | 132008 | Using index condition; Using temporary; Using filesort |
| 1 | SIMPLE | us | eq_ref | PRIMARY | PRIMARY | 46 | dwh0.FACT.USER,dwh0.FACT.ENV | 1 |
|
+------+-------------+-------+--------+----------------------------+----------------------------+---------+------------------------------+--------+--------------------------------------------------------+
2 rows in set (0.001 sec)
Can anyone refer to such a problem? the where clause is generated by grafana, so i can not change that, but the rest i can change if it changes something.
Thanks for suggestions!
Sorry for bothering.. after around 10^5 more inserts, it works for both cases... Maybe it was just bad luck

How to convert the jsonb datatype to other datatype in psql for amazon quicksight

My Psql database has a table which has jsonb as type for some columns, when i tried to upload these tables in amazon quicksight for some analysis purpose, am getting an error says unsupported datatype and the columns are getting skipped in amazom Quicksight.
Please help me to convert these into some supported type in amazon Quicksight.
Column | Type | Collation | Nullable | Default
---------------+-----------------------------+-----------+----------+-----------------------------------------------
id | bigint | | not null | nextval('solera_progresses_id_seq'::regclass)
milestones | jsonb | | |
reference_id | character varying | | |
response_code | integer | | |
activity | jsonb | | |
response | jsonb | | |
user_id | bigint | | |
You can use custom SQL to convert the data to the supported type before loading to Quicksight.
For instance, if your jsonb column contains objects like {"name": "John"}, you can create a column name in Quicksight using the query:
SELECT column_name->'name' AS name
FROM table_name

Getting App Maker to respect the order of a many-to-many relation

I'm having some trouble getting App Maker to respect the order of a many-to-many relation.
Let's say I have two models:
Model 1 has an ID and a many-to-many relation to model 2 which also has an ID.
App maker generates three tables:
DESCRIBE model_1;
+--------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+--------------+------+-----+---------+----------------+
| Id | int(11) | NO | PRI | NULL | auto_increment |
+--------------------+--------------+------+-----+---------+----------------+
DESCRIBE model_2;
+--------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+--------------+------+-----+---------+----------------+
| Id | int(11) | NO | PRI | NULL | auto_increment |
+--------------------+--------------+------+-----+---------+----------------+
DESCRIBE model_1_Has_model_2;
+------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------+---------+------+-----+---------+-------+
| parentModel1_fk | int(11) | NO | MUL | NULL | |
| childModel2_fk | int(11) | NO | MUL | NULL | |
+------------------+---------+------+-----+---------+-------+
Now let's say I have a model_1 object with ID 1 and three model_2 objects with IDs 1, 2, 3. If I assign model_1.childModel_2 to [model_2_ID_1, model_2_ID_2] the model_1_Has_model_2 table will contain:
parentModel1_fk | childModel2_fk
--------------------------------
1 | 1
1 | 2
Now let's say I splice model_1.childModel_2 using model_1.childModel_2.splice(0, 1) and then insert model_2 ID 3 in index 0 using model_1.childModel_2.splice(0, 0, model_2_ID_3). I would expect my table to contain the following:
parentModel1_fk | childModel2_fk
--------------------------------
1 | 3
1 | 1
However it contains the opposite:
parentModel1_fk | childModel2_fk
--------------------------------
1 | 1
1 | 3
Is there any way I can stop this behavior short of clearing the entire relation and then setting it to my new expected order?
The short answer is no. App Maker is just creating a new record, not rearranging the table. Otherwise it would have to edit all the records below the desired insertion point (which could be a prohibitively time consuming transaction). If this is the desired functionality, you'll have to do it manually.
I would seriously consider creating your own join table that will allow you to have additional columns, where you can store the desired sort order.

Strange syntax error when changing type of a column

I'm trying to change the type of 2 columns. The first works but the second gives a syntax error for the same command:
> show full columns from KernelParams;
+-------+------------------+-------------------+------+-----+---------+----------------+---------------------------------+---------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment |
+-------+------------------+-------------------+------+-----+---------+----------------+---------------------------------+---------+
| id | int(10) unsigned | NULL | NO | PRI | NULL | auto_increment | select,insert,update,references | |
| param | varchar(256) | latin1_swedish_ci | YES | UNI | NULL | | select,insert,update,references | |
| desc | varchar(256) | latin1_swedish_ci | YES | | NULL | | select,insert,update,references | |
+-------+------------------+-------------------+------+-----+---------+----------------+---------------------------------+---------+
> ALTER TABLE KernelParams MODIFY param varchar(128);
Query OK, 6 rows affected (0.08 sec)
Records: 6 Duplicates: 0 Warnings: 0
> ALTER TABLE KernelParams MODIFY desc varchar(128);
ERROR 1064 (42000): 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 'desc varchar(128)' at line 1
Any ideas what is wrong there?
DESC is a reserved word, so you need to quote the column name, like OTTA said in their comment. The table and column quoting character in MySQL and MariaDB is the backtick (`)
ALTER TABLE KernelParams MODIFY `desc` varchar(128);
This works as expected:
MariaDB [test]> describe new_table;
+-------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+-------------+------+-----+---------+-------+
| idnew_table | int(11) | NO | PRI | NULL | |
| desc | varchar(45) | YES | | NULL | |
+-------------+-------------+------+-----+---------+-------+
2 rows in set (0.02 sec)
MariaDB [test]> ALTER TABLE new_table MODIFY `desc` varchar(128);
Query OK, 0 rows affected (0.03 sec)
Records: 0 Duplicates: 0 Warnings: 0
MariaDB [test]> describe new_table;
+-------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| idnew_table | int(11) | NO | PRI | NULL | |
| desc | varchar(128) | YES | | NULL | |
+-------------+--------------+------+-----+---------+-------+
2 rows in set (0.02 sec)

Resources