View Issue Details

IDProjectCategoryView StatusLast Update
0006937mantisbtadministrationpublic2006-05-07 03:51
Reportermishka Assigned Toryandesign  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0006937: MySQL Compability v.4 and v.5
Description

In function custom_field_get_all_linked_fields( $p_bug_id ) at custom_field_api
the query works fine on v.4+ but fails on v.5+ (I use 5.0.18).
The error arises after an attemp reassign issue.
See Add. Info.

Additional Information

the hereunder query structure fits MySQL v. 4+ but fails at v. 5+

$query = "SELECT f.name, f.type, f.access_level_r, f.default_value, f.type, s.value
FROM $t_custom_field_project_table AS p, $t_custom_field_table AS f
LEFT JOIN $t_custom_field_string_table AS s
ON p.field_id=s.field_id AND s.bug_id='$c_bug_id'
WHERE p.project_id = '$c_project_id' AND p.field_id = f.id
ORDER BY p.sequence ASC, f.name ASC";

the following query functional under both MySQL v. 4+ & 5+

$query = "SELECT f.name, f.type, f.access_level_r, f.default_value, f.type, s.value
FROM $t_custom_field_table AS f
LEFT JOIN $t_custom_field_project_table AS p
ON f.id = p.field_id
LEFT JOIN $t_custom_field_string_table AS s
ON p.field_id=s.field_id
WHERE p.project_id = '$c_project_id' AND s.bug_id='$c_bug_id'
ORDER BY p.sequence ASC, f.name ASC";

TagsNo tags attached.

Relationships

duplicate of 0006394 closedthraxisp Unknown column p.field_id when closing bug when using MySQL >= 5.0.12 

Activities

grangeway

grangeway

2006-04-17 08:51

reporter   ~0012518

as I dont have mysql 5 installed, do you happen to have the error message it generates handy?

mishka

mishka

2006-04-17 10:52

reporter   ~0012525

Last edited: 2006-04-17 10:54

I hope i'm getting you right and You're asking for error message, so given hereunder:


APPLICATION ERROR 401
Database query failed. Error received from database was #1054: Unknown column 'p.field_id' in 'on clause' for the query: SELECT f.name, f.type, f.access_level_r, f.default_value, f.type, s.value
FROM mantis_custom_field_project_table AS p, mantis_custom_field_table AS f
LEFT JOIN mantis_custom_field_string_table AS s
ON p.field_id=s.field_id AND s.bug_id='35'
WHERE p.project_id = '76' AND p.field_id = f.id
ORDER BY p.sequence ASC, f.name ASC

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.


I have MySQL 5.0.18 on production server but on my local mashine installed v.4.0.+ so when I tried to run the the query via phpAdmin on v5.0.18 it triggers error while on my local mashine with v4.0.+ it works fine.
Like I said in Add-Info, the orignal query structure seems to be lousy:
FROM clause defines 2 tables, then one explicit JOIN clause and then one more implicit JOIN in WHERE clause + constraint, not the best query composing style.
Better is:
FROM clause defines a major select table
JOIN block with all additional tables you need
and then in WHERE clause are coming all the constraints U get based on cartesian product table U get as result of defined JOINs.

Neverless that's not the question of style but functionality.

thraxisp

thraxisp

2006-04-21 14:41

reporter   ~0012658

I think that this code was re-writted in the RCs leading up to 1.0.0. Could you upgrade and retest?

mishka

mishka

2006-04-21 16:02

reporter   ~0012661

Unfortunately I can't upgrade and re-test it. I'm pretty much in final stages to launch my production server. The whole thing rised up while switching Mantis from local mashine configured with MySql v4.0.+ to production server with MySQL 5.0.18. Right now I'm fully syncronized between local mashine and production one, so I don't even have older MySQL v.4 installed and available.
I fixed the problem changing the query structure like I mentioned in my note but if You guys already took care of that then ... np.
I just thought that it might be helpful.

ryandesign

ryandesign

2006-04-23 08:33

reporter   ~0012687

It was fixed in 1.0.0a1; see 0006394.