Check if doctrine relations are correct - orm

Is it possible to check if the relations between models are correct?
Im looking for cli command or something like Symfony2 profiler which shows wrong relations.

There is a build-in command that Validate that the mapping files are correct and in sync with the database:
./bin/doctrine help orm:validate-schema
'Validate that the mapping files are correct and in sync with the
database.'
In the symfony2 doctrine bundle exists two command instead:
doctrine:schema:validate
The doctrine:schema:validate checks the current mappings for valid
forward and reverse mappings.
and
doctrine:mapping:info
The doctrine:mapping:info shows basic information about which
entities exist and possibly if their mapping information contains
errors or not.

"Using custom column definition trigger schema update every time":
"This is a known limitation that we cannot fix."
https://github.com/doctrine/dbal/issues/2666#issuecomment-283772609

Related

PostgreSQL error : the "PostAudienceEnum" type already exists

I generated a migrate.sql file from the prisma ORM which I then imported into my PostgreSQL database from Query Tool. However when I run this file I get the error: the "PostAudienceEnum" type already exists . I don't know why yet I did declare PostAudienceEnum as an enum . Here are the lines where we find the enumeration PostAudienceEnum:
-- CreateEnum
CREATE TYPE "PostAudienceEnum" AS ENUM ('PUBLIC', 'FRIENDS', 'ONLY_ME', 'SPECIFIC');
CREATE TABLE "Post" (
...
"audience" "PostAudienceEnum" NOT NULL DEFAULT E'PUBLIC',
...
CONSTRAINT "Post_pkey" PRIMARY KEY ("id")
);
This file was designed from my prisma schematic. I don't know how to modify it without messing up my database and why PostgreSQL throws this error.
You might be getting this error if the database already has data, and you're attempting to manually execute the SQL file against the database. You should only use prisma migrate to manage changes in your schema against your database. Prisma internally records what migrations have and have not been executed against the database, and attempting to run an SQL file manually outside of prisma migrate defeats the purpose of using it in the first place.
Migrate docs: https://www.prisma.io/docs/concepts/components/prisma-migrate
You should ONLY use Prisma Migrate to make changes to your database tables/columns/relationships, and not an external tool. However, if you are developing your database FIRST and then looking to keep your Prisma schema up to date with your database (and not the other way around), you will want to introspect your database. Same deal applies: Prisma knows what parts of your database are reflected in your Prisma schema and what's not.
Introspection docs: https://www.prisma.io/docs/concepts/components/introspection

'DBT docs generate' does not populate model column-level comments in the catalog

I use dbt-snowflake 1.1.0 with the corresponding dbt-core 1.1.0.
I added documentation for my models in yaml files, i.e.:
> models/stage/docs.yml
version: 2
models:
- name: raw_weblogs
description: Web logs of customer interaction, broken down by attribute (bronze). The breakdown is performed using regular expressions.
columns:
- name: ip
description: IP address from which the request reached the server (might be direct customer IP or the address of a VPN/proxy).
...
Although these details show up correctly in the DBT UI when i run dbt docs generate and then dbt docs serve, yet they are not listed in target/catalog.json:
cat target/catalog.json | grep identity
(no results)
According to the DBT documentation, I understand that column comments should be part of catalog.json.
LATER EDIT: I tried running dbt --debug docs generate and it seems that all data is retrieved directly from the target environment (in my case, Snowflake). Looking at the columns of my model in Snowflake, they indeed do NOT have any comments posted on the in Snowflake.
It thus seems to me that the underlying error might be with the fact that dbt run does not correctly persist the column metadata to Snowflake.
After further investigation, I found out the reason for lacking comments was indeed the fact that the comments are written to catalog.json when running dbt docs generate based on what is received from the database, while dbt docs serve populates the UI by combining information from catalog.json with metadata (in my case, documented column comments) from the local dbt models.
The solution to persist such metadata in the database with dbt run was to add the following DBT configuration:
> dbt_project.yml
models:
<project>:
...
+persist_docs:
relation: true
columns: true

DBT manifest.json data type is null

I'm creating a lot of stuff based on the manifest.json that dbt generates for me. But for whatever reason the "data_type" property for each column is always None in the manifest.json, even though I can see it in the catalog.json, I believe the data type is generated from the database.
How do I get the data_type attribute populated in my manifest.json file ?
Some helpful answers from this dbt Slack thread:
first reply (h/t Daniel Luftspring)
not sure if this is the only way but i'm running dbt version 0.20.1 you can specify the data_type as a column property in your schema.yml and it will show up in the manifest like so:
columns:
- name: city
data_type: string
If you have a big project and wanted to automate this you could probably pull together a script to edit your schema files in place and sync the data types with your db using the information schema
second reply (h/t Jonathon Talmi)
FYI catalog.json has data type becaause it queries the metadata data
tables in your dwh (e.g. info schema in snowflake) to contruct the
catalog, but your traditional dbt compile/run/etc which. generates a
manifest does not have such queries

Generating DB schema from model in Yii

Is there way to generate mysql schema from Yii model? In model i describe fields and relations. So it is enough to generate/update db structure.
Like symfony 2 command line:
php console/app doctrine:schema:update
No, in yii a models attributes are dynamic and come from the database. Any properties defined in the model are not attributes and therefore not in the database. For this reason if you add a new column to the post table the Post model will automatically have a magic property of that column.
What I think you're after are Migrations

NHibernate (and Fluent): Possible to prevent a specific table from being created via SchemaExport.Create?

I'm using Fluent NHibernate (and I'm a newbie). I have mapped a read-only table that already exists in the database (it's actually a view in the db). In addition, I have mapped new classes for which I want to create tables using SchemaExport.Create().
In my fluent mapping, I have specified "ReadOnly()" to mark the view as immutable. However, when I execute SchemaExport.Create(), it still tries to create the table so I get the error "There is already an object named 'vw_Existing'".
Is there a way to prevent NHibernate from trying to create that specific table?
I supposed I could export and modify the sql (SetOutputFile), but it would be nice to use SchemaExport.Create().
Thanks.
You're looking for
SchemaAction.None();