]
Christoph John updated TEIID-5589:
----------------------------------
Workaround Description:
No general workaround found yet. However, what is working for me is to change the primary
key from a string value to an integer. I could fortunately do this, as I have a special
situation with a table which holds uuids mapped to their internal database counterparts
which are IDs of type integer. Hence, in my case both columns qualify as primary keys.
Note, when using Teiid Designer it was not sufficient for me to reimport the database
source and sync the vdb. I had to create and configure an entirely new vdb to get things
working. Might be that I hit another issue here with Teiid Designer.
was:No general workaround found yet. However, what is working for me is to change the
primary key from a string value to an integer. I could do this as I have a table with a
special case in which uuid are mapped to their internal database counterparts which are
IDs of type integer. Note, when using Teiid Designer it was not sufficient for me to to
reimport the database source and sync the vdb. I had to create and configure an entirely
new vdb to get things working. Might be that I hit another issue here with Teiid Designer.
NavigationProperty not working with Teiid odata, results in
TEIID16053
------------------------------------------------------------------------
Key: TEIID-5589
URL:
https://issues.jboss.org/browse/TEIID-5589
Project: Teiid
Issue Type: Bug
Affects Versions: 11.2.1
Reporter: Christoph John
Assignee: Steven Hawkins
Priority: Blocker
Attachments: AccountRecord.xml, metadata.xml
Teiid throws an error in case it tries to follow an odata Navigation property. I tried
this by using $expand and also by directly following a path. Two examples are shown below.
My $metaddata.xml file is attached, and also a single record from the Account table in
which the relevant comparison seems to happen. the uuidUser property you can find here.
I do not understand the error message. What is not clear to me is the assignment which is
mentioned there g1.uuidUser = g0.fkProfile
Just for your awareness, uuidUser and fkProfile are different columns of different types
that should not be compared in anyway. Maybe this is a hint what is going wrong. I would
the relevant NavigationProperty expect to be
<NavigationProperty Name="fkProfileInProfile"
Type="my_nutri_diary.Account" Nullable="false">
<ReferentialConstraint Property="fkProfile"
ReferencedProperty="idProfile"/>
Here are two example queries which fail with the same error
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)?$expand=fkPro...
http://localhost:8080/odata4/vdb/my_nutri_diary/Profile(38)/fkProfileInPr...
<error
xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding
character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
----------------------------
Update 9.1.19: I need to to add here, that there might be a second bug involved into the
observation. It seems, that the error is due to type comparisons. As there was a
comparison with Account.uuuiUser in the error message and as my table Account just holds a
one to one mapping between uuids and integers which represent database internal IDs, I
switched the primary key in the Account table from uuidUser to idProfile in hope to
circumvent the bug.
So my new observation is, when I disable row constraints in which I must have a
comparison against uuidUser in the form "Profile.fkProfile in (SELECT
Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36))" and switch
hte primary key as mention previously, than I can follow the navigation property. However,
as soon as I enable row constraints again I get a similar error message as before:
<error
xmlns="http://docs.oasis-open.org/odata/ns/metadata">
<code>TEIID31172</code>
<message>
TEIID31172 Could not resolve expressions being compared to a common type excluding
character conversions: g1.uuidUser = g0.fkProfile
</message>
</error>
As I am not sure if the issue derives from the same place in code, I thought I should add
this here.