I am trying to make a select statement that selects the image names from a MySQL database. The table is called — pictures_archive. I am also trying to select these pictures depending on the category they have. The code is:
It gives me an «#1242 — Subquery returns more than 1 row» error. I can see why, but can’t figure it out how to do it.
Содержание
- Comments
- smyrman commented Feb 18, 2016
- This comment has been minimized.
- kenshaw commented Feb 18, 2016
- This comment has been minimized.
- kenshaw commented Feb 18, 2016
- This comment has been minimized.
- smyrman commented Feb 18, 2016
- This comment has been minimized.
- kenshaw commented Feb 18, 2016
- This comment has been minimized.
- kenshaw commented Feb 18, 2016
- This comment has been minimized.
- kenshaw commented Feb 18, 2016
- This comment has been minimized.
- smyrman commented Feb 18, 2016
- This comment has been minimized.
- smyrman commented Feb 18, 2016
- This comment has been minimized.
- kenshaw commented Feb 18, 2016
Comments
Copy link Quote reply
smyrman commented Feb 18, 2016
I get the error described in the header when I try to run xo against my MySQL schema. Is there any flags/env vars to print debug info, e.g. so I could finding out which query that crashes it?
This comment has been minimized.
Copy link Quote reply
kenshaw commented Feb 18, 2016
Could you copy and paste the actual command line you issue and the actual error output by xo? Also, could you provide more information about the schema design you are using? I don’t need the entire schema, just some basics.
The queries that generate the MySQL are in the project root’s ./gen.sh. It’s likely the ‘mysql columns query’ which uses some sub queries. Without seeing the schema it would be difficult for me to track this down.
I will make a point to enable a ‘verbose’ flag to output the SQL queries as they are being run by xo. Give me a few hours to write this code, as I have something that is already ‘half-finished’ but still need to roll it out / test it.
This comment has been minimized.
Copy link Quote reply
kenshaw commented Feb 18, 2016
If you pull the latest code, I have ‘fixed’ the —verbose/-v option on xo command line:
If you could retry this and copy the specific SQL statement that is occurring right before the error, I can figure out the issue and likely fix it, depending on your schema.
Additionally, when using the generated code, you can set a logging func XOLog, a la this:
BTW — I’m fairly certain of where the error is already, but I need to figure out a clever way to fix the MySQL query while still producing valid info for use by the templates.
This comment has been minimized.
Copy link Quote reply
smyrman commented Feb 18, 2016
Thanks for the verbose flag.
Anyway. The original command line output was just the tile of this ticket, nothing else.
My setup is using Docker. I found the issue only happens if the mysql version is 5.5 for me — more or less exactly the same database within a mysql:5.7 container causes no issues. Maybe it’s not critical to support mysql as old as 5.5?
The schema of the whole DB is a pretty big django generated DB.
Here is command output when using the new verbose flag:
This comment has been minimized.
Copy link Quote reply
kenshaw commented Feb 18, 2016
Thanks — could you connect and do the following on mysql?
SHOW INDEXES FROM django_db;
I’m assuming that’s django, so I’ll try to find the schema online and create it and debug from this end.
Unfortunately, I don’t have any «complex» schemas to test against unlike in PostgreSQL/Oracle, so I really appreciate the assistance.
This comment has been minimized.
Copy link Quote reply
kenshaw commented Feb 18, 2016
Quick update — I installed the basic django installation and am working with the schemas now. I should have this figured out «soon», but it’s the end of the work day for me here.
This comment has been minimized.
Copy link Quote reply
kenshaw commented Feb 18, 2016
I found what the issue is / where the mistake in the code is. I’ll need some time to fix it.
This comment has been minimized.
Copy link Quote reply
smyrman commented Feb 18, 2016
Cool — sorry for my late response.
I’ll need some time to fix it.
That’s no problem. Sorry for my late response time. Currently I am testing XO on my own time, and not at work.
This comment has been minimized.
Copy link Quote reply
smyrman commented Feb 18, 2016
I’m assuming that’s django, so I’ll try to find the schema online and create it and debug from this end.
django_db is actually the name of our DB, so I am afraid you won’t find the schema for (all of this at least) online all the tables generated from Django model code.
In the command I posted earlier, the «django_db» is actually db_name — it contains a larger collection of tables generated from Django 1.8 models. Some of the other variables (myproject, myproject_db_container) is not the actual values I used for our project.
docker run —net myproject_default —link myproject_db_container:db —rm -v $PWD/myapp/:/mnt/ kaizen/go-xo xo mysql://kaizen:test@db/django_db -o /mnt -v —schema django_db
I might be able to see if I can reproduce the issue with a schema I can actually share on my own time.
This comment has been minimized.
Copy link Quote reply
kenshaw commented Feb 18, 2016
You don’t need to track the issue down. The issue is exactly where I originally thought it was, which is multiple index names being returned for the same column. This is also an issue in the postgres code. The oracle code that I haven’t released yet builds indexes differently, and the sqlite code that I pushed out yesterday also builds indexes differently. I was trying to be «too clever» with the postgres/mysql code. Anyway, I know how to change it, but it’s somewhere between trivial and hard as I need to rewrite quite a bit of code for it to be correct. It’ll get done very quickly, however. I’m glad that you had this issue with Django, as its a complex enough base schema to test against for a variety of databases, and seems to be relatively well-designed schema. I’m now making a point to get xo to work with all the django schema out of the box.
И всем снова привет, решил еще написать как победить ошибку которая у меня возникла при работе с сайтом на Opencart по светодиодному освещению Арлайт моего клиента, данная ошибка у меня возникла когда я решил зайти и отредактировать категории и при заходе получал белый экран и ошибку:
если посмотреть в лог на сервере то увидим такую картину (как включить лог на ошибки читайте мою прошлую статью)
В итоге эту ошибку можно победить след образом:
- Открыть phpMyAdmin
- найти таблицу oc_url_alias
- почистить значения
в моем случае было так, я весь товар и категории удалял через phpMyAdmin и где то остались хвосты и в итоге вновь созданные категории с их id пересеклись со старыми.
ИТОГ: зайти в таблицу oc_url_alias и удалить явно ненужные значения
Источник: