To my dismay (after being so excited to use it), CheckConstraints are not available on MySQL DBs less than 8.0.16. I'm using MySQL 5.7 and doesn't look like I'll be updating any time soon.
I'm using Django v2.2 and wanted to apply the new constraints to my DB:
https://docs.djangoproject.com/en/2.2/ref/models/constraints/
(The docs may need to be updated to say that check constraints don't work with MySQL versions less than xyz)
I want to know if anyone has a good working alternative for this use case.
I've currently whipped up a signal on pre_save to raise an IntegrityError if the constraint matches.
#receiver(pre_save)
def object_constraint(sender, instance, **kwargs):
if issubclass(sender, MyClass):
if instance.constraint_is_met:
raise IntegrityError("What are you even...?")
Thanks
Related
I have inherited an application that uses MySQL and that is used by a PHP front end. The guy that wrote this system has gone to some fairly convoluted lengths to ensure that codes that users enter are valid - and tat means that these codes also exist in another table.
When I first saw this I wondered why he hadn't used CHECK constraints and let the dbms sort this out - I have visions of a load of different programs implementing the same checks instead of just the one place in the dbms. And then I found out that MySQL doesn't support Check constraints (not strictly true - it supports the syntax but just ignores it).
Is there a way that I can implement Check Constraints in MySQL?
Any hints, suggestions etc, would be great.
You can implement something similar to them with triggers, but MySQL itself (before version 8.0.16) doesn't support CHECK constraints. Don't worry though, it'll let you define them and just silently ignore them!
I am trying to setup foreign key for my mysql database using phpmyadmin.
But phpmyadmin only displays internal relation in 'relational view'. Note I have already made sure of following steps.
Setup phpmyadmin database (create_table.sql and config stuff)
Made sure all tables in my database using InnoDb
Made sure my intended foreign keys/reference Keyes are indexed.
After all these steps I can only see internal relations in my relational view.
Am I missing something?
This is not actually a solution, but since I cannot comment on posts yet, I'll add a few comments that might help.
I've faced this same issue and the critical parameters seem to be the following:
Case insensitive operating system (in my case windows)
Mixed-case table names (e.g. "TableName")
I've been using Mixed-case table names successfully in Linux, but in Windows something seems to go really wrong with phpMyAdmin.
I bet your table names are mixed-case. Try creating a test table yourself, with a fully lowercase name, and check if you see the "Foreign Key Relations" options of phpMyAdmin.
If you do, then we've found the source of the problem and we're just left with finding a solution or workaround for it :)
ps: More on case-sensitivity and mysql, without any hints about phpMyAdmins view on all of this, can be found here:
http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
This IS the solution. Renaming table name 'myTable' to 'my_table' solves the problem.
If you have different storage engines on the tables in your database, this would be the case. The only storage engine I know to support foreign keys is InnoDB. MyISAM and the rest don't seem to work.
Change your Storage Engine to: innoDB and then click save.
I have a new client that is running a Symfony application with 170 or so MySQL tables. He recently updated his MySQL Workbench to the latest revision and is now getting a warning pop-up when he launched the application
FIX INDEX NAMES
Index names identical to FK names were found in the model, which is not allowed for MySQL5.5 and later. Would you like to rename the indexes?
I am not a DBA but I understand that the index and primary key names are clashing. What are the implications of renaming these indexes vs. just ignoring?
The Symfony app he is running uses the Doctrine ORM, would any queries or the model need to be updated should the indexes be renamed?
Using the InnoDB engine
Thanks
MySQL Workbench checks at opening a model if there are any duplicate index names and offers to rename them to be unique. Letting it doing this has not bad side effect. In fact it is even necessary to be able to apply the model to a server. Otherwise the server will refuse to create tables that contain an index with a name that was already taken.
So in short: it's a good idea to let Workbench fix this bug (since duplicate key names are nothing but a bug).
I'm trying to connect to an Informix database with SQLAlchemy. All my tests seem to show the connection is working; however, whenever I try and perform a read of the database I get the error:
DatabaseError: (DatabaseError) SQLCODE -217 in PREPARE:
IX000: Column (current_role) not found in any table in the query (or SLV is undefined).
'select CURRENT_ROLE from systables' ()
Now the database that I am connecting to doesn't have CURRENT_ROLE, so how can I get round this?
My interactive traceback of the error is shown below in a gist:
https://gist.github.com/2157378
The offending line is:
File "build/bdist.linux-i686/egg/sqlalchemy/dialects/informix/base.py", line 593, in _get_default_schema_name
return connection.execute('select CURRENT_ROLE from systables').scalar()
Is there any workaround for this problem?
I am now led to believe this is a bug in SQLAlchemy (after talking to users in #sqlalchemy) and I have filed a bug report:
http://www.sqlalchemy.org/trac/ticket/2448
You've not identified which version of IBM Informix Dynamic Server (IDS) you are using or which platform you are using it on, so it is hard to help you.
It appears that SQLAlchemy expects a more recent version of Informix than you are using. Somewhat to my surprise, the niladic function CURRENT_ROLE appears to be available in IDS 11.70 (tested on 11.70.FC4 on RHEL 5 for x86/64). It was not recently added, so it will be in any 11.70 version, and possibly in some earlier versions (but not as early as the version you are using).
I'm not sure how much of a bug it is in SQLAlchemy. If the version of Informix that you're using is really old, there is limited virtue in them adding support for it. You can find out which version you're using by running:
SELECT DBINFO('version', 'full')
FROM 'informix'.systables
WHERE tabid = 1;
If that doesn't work, you are many years out of date with your server.
Addendum
Thinking about it a bit more...I wonder what SQLAlchemy is going to do with the role. It probably shouldn't be trying to analyze whether you have permission; it should try an operation and deal with failures. That will be quicker, especially in the common case where you actually do have permission.
There could be two issues:
SQLAlchemy should be aware that some (as yet indeterminate) list of old versions of IDS do not support CURRENT_ROLE.
SQLAlchemy should review why it needs to be aware of the current role.
I'm using MySQL workbench 5.2.35 CE to reverse a Mysql Database and show the diagram of tables with their relationships.
I am able to get every table and its fields but the relations between them is not shown. Why is that? Is there any way it can be fixed?
Most often, the relations between tables are not stored in the DB. How to combine two tables is entirely up to the SQL query and because there are near endless possibilities to name your columns this is not easy to guess. Try to find some SELECT statements or use brute force to find out wich columns match.
If you are using MyISAM as the database engine, your database is not fully relational. Make your database fully relational by using InnoDB engine. Then you will be able to see the relations when you do reverse engineering. But please note that each has pros and cons of its own. Google MyISAM vs InnoDB to find out more about the differences.
I have tested mysql-workbench for both 5.2 and 6.0 latest version. My database got foreign key constraints defined clearly. My database is using mysql-native SQL. But the relationships are shown as line between tables. I have created another test database with only two tables. In this case the InoDb was used as engine. The foreign key constrain clearly defined. Still it only generate two lonely table object in the ER diagram after going through the "reverse engineering" module.
While using another commercial software, I was able to generate the 'lines' between the Entities.
My question is, is this a problem of workbench itself, or some error on my part. My database server is the latest stable version 5.6.12. If I can get an answer, this will be good for everyone. You don't have to waste time trying to get an ER-diagram with this piece of software.