I am new to symfony and doctrine and would appreciate some help ...
I am connecting doctrine to an oracle 11g database.
I have created an table/entity which contains nullable date fields.
The fields are described in YAML thus
metar_time:
type: date
nullable: true
column: METAR_TIME
taf_time:
type: date
nullable: true
column: TAF_TIME
ltaf_time:
type: date
nullable: true
column: LTAF_TIME
storage_date:
type: date
nullable: true
column: STORAGE_DATE
The database schema reflects the status of the fields as nullable dates with a default value of null.
The issue that I am having is that I can not get doctrine to recognise that the database and meta description are in sync.
php app/console doctrine:schema:update --dump-sql
ALTER TABLE MET MODIFY (LTAF_TIME DATE DEFAULT NULL, METAR_TIME DATE DEFAULT NULL, STORAGE_DATE DATE DEFAULT NULL, TAF_TIME DATE DEFAULT NULL);
php app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "1" queries were executed
Yet if I run the sql dump again the update is still outstanding.
I have cleared all the caches to rule that out as an issue.
Any suggestions welcome !
This is known issue. Check Incorrect type mapping on Oracle Platform
Some ref:
The problem is that Oracle has a "DATE" type, which is actually a DATETIME. That is why we map it to Doctrine's Datetime type.
As a workaround, you can set this information yourself using:
$conn->getDatabasePlatform()->registerDoctrineTypeMapping('date', 'date');
Be aware this is a global change for all columns. If you map DateTimes to a TIMESTAMP field you are good to go though.
Related
Laravel Version: ^9.27
PHP Version: 8.1
Database Driver & Version: Postgresql 14.X
Description:
I use different names for standard date fields, see below.
I also include these data type fields in the cast.
Definitions of these fields in the PostgreSQL database
my timezone configuration
'timezone' => 'America/Sao_Paulo',
see the data in the database
return date
value that should have saved and returned
2022-10-05T12:17:04-03:00
postgresql timestamp is correct America/Sao_Paulo
What is the meaning of nullable() in Laraval migration?
For example, this is in our migration:
$table->string('middle_name')->nullable();
It means the middle_name field can also store null values: as in inserting a value is not required.
Imagine a registration form for example. Not everybody has a middle name. So in that case they would leave the middle_name field empty and in the database it'll be null.
This is equivalent in MySQL statement "DEFAULT NULL", when we declare a column of a MySQL Table.
`imageURL` varchar(255) DEFAULT NULL,
is equal to Laravel's
$table->string('imageURL',255)->nullable();
Then if it's default value is NULL, when we perform an INSERT statement without mentioning a value for that column, the value would be inserted as NULL.
It will make the column nullable in the database which means you can store null values to that column or also can be said that it is not a mandatory field in database
My migration is like so:
$table->bigIncrements('id');
$table->timestamp('from_date');
$table->timestamp('to_date');
$table->timestamps();
The problem is that when I migrate it, the second one which is from_date automatically gets on update CURRENT_TIMESTAMP attribute so it means when I update other columns this column will be updated too. That's what I don't want. How can I prevent it?
You can add nullable to the column in order to remove the constraint.
$table->timestamp('from_date')->nullable();
Unfortunately I think that this is the only solution. Then you can add a form validation in order to prevent setting null value for the field.
-- EDIT
$table->timestamp('from_date')->default(DB::raw('CURRENT_TIMESTAMP'));
// or
$table->timestamp('from_date')->useCurrent();
Try this as well, I believe this is what the created_at has.
You need to make the DateTime column nullable, then MySQL won't add that. By default, MySQL adds that to the first timestamp in the table, unless explicitly told not to (via allowing a null value for the field). This is a MySQL thing, not a Laravel thing.
$table->timestamp('colName')->nullable();
Read :
Automatic Initialization and Updating for TIMESTAMP and DATETIME - MYSQL DOCS
Laravel & MySQL auto-adding “on update current_timestamp()” to timestamp fields
This behaviour is native to MySQL. You can read about it on this documentation page:
TIMESTAMP and DATETIME columns have no automatic properties unless they are specified explicitly, with this exception: If the explicit_defaults_for_timestamp system variable is disabled, the first TIMESTAMP column has both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP if neither is specified explicitly.
The docs go on to specify that there are two strategies for avoiding this behaviour:
Enable the explicit_defaults_for_timestamp variable in your database configuration.
When defining your timestamp column, specify a DEFAULT or make the column nullable.
I'm working on migrating all the tables in my schema to be partitioned tables. Since I'm on 11g instead of 12.2 I have to use DBMS_REDEFINITION. I've automated this with some Ruby code that executes the redefinition procedures for each table in my schema.
My issue is that after migrating, all of my non-nullable columns show NULLABLE - YES. This isn't actually true however, as I can check the constraints and there are check constraints defined for each of the columns that used to be NOT NULL, still enforcing the NOT NULL status. It seems like DBMS_REDEFINITION successfully copied the constraints, but it didn't reflect the NULLABLE status.
Is there a way to tell Oracle to get this back in sync?
I found the answer elsewhere:
https://dba.stackexchange.com/questions/55081/why-is-sqlplus-desc-table-not-showing-not-null-constraints-after-using-dbms-re
Oracle copies the constraints but never turns validate back on. You have to manually do that with:
ALTER TABLE <table_name> ENABLE VALIDATE CONSTRAINT <constraint_name>;
I have been struggling with defining cascade behavior in Doctrine ORM.
According to the documentation, one is supposed to use onDelete: CASCADE for database-level cascade (which is what I am trying to achieve here).
A complete example may be seen on the Symfony tutorial.
However, all such cascade specifications are ignored in my schema.
Here is the relevant excerpt:
Advancement:
columns:
association_id:
type: integer(4)
notnull: true
task_id:
type: integer(4)
notnull: true
state:
type: enum
values: ['todo', 'current', 'done', 'cancelled']
notnull: true
relations:
Association:
class: Association
local: association_id
foreignType: one
onDelete: CASCADE
Task:
class: Task
local: task_id
foreignType: one
onDelete: CASCADE
Of course, the Task and Association tables are defined correctly. I won't post them here in the first place to avoid a too long question, but please ask if that seems necessary.
Here is the generated SQL (linebreaks mine):
CREATE TABLE advancement
(id INTEGER PRIMARY KEY AUTOINCREMENT,
association_id INTEGER NOT NULL,
task_id INTEGER NOT NULL,
state VARCHAR(255) NOT NULL);
Not a trace of a CASCADE (nor a REFERENCES, by the way…). Of course, cascading does not work, and I had to implement it manually by altering the default backend actions.
Does anyone know what I am doing wrong here?
I think doctrine will shut up about the fact that your RDBMS (is it MySQL?) does not support cascades if it doesn't. This is the case if you use MySQL with the MyISAM storage engine (which does not support REFERENCES either, by the way...). If I were you, I'd try to create a cascade directly with your RDBMS client, just to check whether it is possible or not.