Bug-fix needs your vote: queries w/ joins against SQLite return incorrect values because Adobe treats PK col as alias for rowid when it should not

Question

For someone new to Adobe the forums and products can be bewildering. I've been advised to repost something I posted in Flash Data Integration in this forum.
Here is the link to the post I put there:
http://forums.adobe.com/message/2363777#2363777
I have reported this bug: http://bugs.adobe.com/jira/browse/FB-23750
I gather bugs get fixed if people vote for them to be fixed. Please vote for it to be fixed. It is serious, and you might not even realize you're suffering from it because the incorrect values returned by the query will seem perfectly plausible.
If the link above doesn't work, here it is again:
When I execute the following query in Flex and/or Lita:
select wrdid, uspelling from WRD WHERE uspelling = 'wingeard'
the results are:
uspelling...wrdid
wingeard   3137
Look at what comes back when I execute this query using .NET provider by  Robert Simpson for SQLite and SQLite Manager by Mrinal Kant:
SELECT     rowid, wrdid, uspelling
FROM         WRD
WHERE     (uspelling = 'wingeard')
rowid.......wrdid...........uspelling
3137........3042............wingeard
No wonder none of my queries with joins is working correctly in Flex.
wrdid is defined as "int" not INTEGER.
http://www.sqlite.org/lang_createtable.html (see INTEGER PRIMARY KEY section):
"The special behavior of INTEGER PRIMARY KEY is only available if the type name is exactly "INTEGER" (in any mixture of upper and lower case.)  Other integer type names like "INT" or "BIGINT" or "SHORT INTEGER" or "UNSIGNED INTEGER" causes the primary key column to behave as an ordinary table column with integer affinity and a unique index, not as an alias for the rowid."  [emphasis added]
Now, I happen to think the SQLite developers made a mistake here in failing to follow standards, preferring not to break legacy code. They'd rather break current code instead???  I would not characterize this as a "corner case" and the bug-at-hand is de facto evidence of that.

Answer 1

Did you try running the queries I posted? What were your results with those?
What I am seeing is that when I use "int PRIMARY KEY" in a CREATE TABLE statement, that column becomes the special "rowid" column. I believe this is also what you are seeing.
However, what confuses me is how you're getting a table with three columns "rowid", "id", and "name" in the first place. When I run this SQL...
CREATE TABLE test
id int PRIMARY KEY,
name String
...I get a table with two columns: a normal column named "name", and a special primary key column named "id", which for this table is identical to the column represented by the rowid identifier.
However, if I understand correctly, your table has three columns, "id", "name", and the special primary key column (i.e. "rowid"). Is that right? Can you give me the SQL that was used to create the table, or tell me how the table was created (e.g. if you used a tool like Lita) so I can try to re-create your exact situation? That would really be very very helpful -- it was the only detail that was missing in your last post, so I had to guess on that one detail.
I tried something else to re-create your situation. I ran the following statement:
CREATE TABLE test
id int
name String
That gave me a table with two real columns plus the rowid column. Then I ran the three insert statements on that table, and when I ran the select statement I got the expected result:
id     name
1     one
2     two
7     seven
Again, I'm guessing that your table was created differently than my test table, and that's the explanation for the difference.
Some other possibilities to consider:
The screen shot doesn't show a SQLResult object, so it seems that you're using some wrapper library or code to execute the query, or at least that you've copied the SQLResult.data Array to another variable named results. Although it seems less likely to me, it's possible that somewhere in that code something is getting scrambled. (But I'd rather rule out AIR as the underlying cause first before attempting to explore those paths.)
As a side note, if you really want the database to have three columns (the special rowid column and your two columns id and name), and you don't want id to be the special rowid column, then it sounds to me like you don't actually want to define id as the primary key. If you just want the id column to have a constraint that prevents duplicate values, you can define it as a UNIQUE column:
CREATE TABLE test
id int UNIQUE,
name String
That gives you the same database-enforced constraint of not allowing duplicate values, but it tells the database explicitly that id isn't the same thing as the rowid primary key. (You can still join another table to the id column even if it's not defined as the primary key.)
P.S. I'm sure you don't mean it this way, but using gigantic red text comes across like shouting -- it's very "loud". I'm trying my best to understand the issue you're having and help you resolve it, and using multiple colors and font sizes doesn't really make your post any more or less clear. Just because I ask you questions, or say that I'm seeing different results than you, doesn't mean I don't believe that you're seeing the results you're seeing. I've definitely seen strange variations and cases where something happens on my computer but others can't duplicate it on their computers -- so I believe that you are getting the results you're getting. I'm just trying to figure out how to make it so that I can also get those results, so that I can pass that on to the engineers who are in a position to make changes.