You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The schema reversal of a rails production database started giving problems, all indexes thata were not unique started being reported as unique. But the development db worked fine.. after some research I was able to track the bug to connection#indexes:
RDB$INDICES.RDB$UNIQUE holds the interesting property
when FB first creates a not unique index, it fills the value with null, and everything works fine (it get's reported as not unique)
but for some reason, after a backup-restore cycle, this value gets changed to '0'
this has been reported here: [http://tracker.firebirdsql.org/browse/CORE-933;jsessionid=EBB3F797BE85B7CF5A6E6199ED6BB064?actionOrder=desc] but it's not a bug, just an inconsistency: "in system tables null and '0' it's the same".
So if according to what I've read online RTEST is the same that "if" for ruby, the problem is that 0 is being evaluated to true: it should test for null or 0.
Maybe this is affecting descending also and other system table tests..
Sorry easy fix but I'm not confident touching c ruby
The text was updated successfully, but these errors were encountered:
The schema reversal of a rails production database started giving problems, all indexes thata were not unique started being reported as unique. But the development db worked fine.. after some research I was able to track the bug to connection#indexes:
fb.c line 2904
So if according to what I've read online RTEST is the same that "if" for ruby, the problem is that 0 is being evaluated to true: it should test for null or 0.
Maybe this is affecting descending also and other system table tests..
Sorry easy fix but I'm not confident touching c ruby
The text was updated successfully, but these errors were encountered: