Issue #642: Unexpected Query Token / Casting in Query

Hi!

Please find the attached database. Doing a simple query with casting

SELECT COUNT(DISTINCT $1) FROM com.quasado.foundation.contact.individual.IndividualContact $1 WHERE UPPER(((com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment) $1.qubletFRAGMENTMAP.get('com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment')).debitorAccount.bankAccounts.routingNumber) LIKE UPPER('%28%')

results in the error

Query Execution Error
=====================
Unexpected query token 'com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment': Identifier is expected
SELECT COUNT(DISTINCT $1) FROM com.quasado.foundation.contact.individual.IndividualContact $1 WHERE UPPER(( ==> (com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment) <==  $1.qubletFRAGMENTMAP.get('com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment')).debitorAccount.bankAccounts.routingNumber) LIKE UPPER('%28%')

.. I'd be so happy to get this stuff finally running :)

Note: Removing the UPPER on both sides stills results in the same error so it's not because of the upper like I've again initially thought ;)

thanks!!

Alex

I fixed some issue in ObjectDB in navigation after casting.

Then I had to add another casting:

SELECT COUNT(DISTINCT $1)
FROM com.quasado.foundation.contact.individual.IndividualContact $1
WHERE
  UPPER(
    ((com.lexware.vereinsverwaltung.abrechnung.api.model.mitglied.MitgliedDebitorenKonto)
       ((com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment)
         $1.qubletFRAGMENTMAP.get('com.quasado.foundation.warehouse.api.model.account.contact.IndividualContactDebitorAccountFragment')
       )
       .debitorAccount
    )
    .bankAccounts
    .routingNumber
  )
  LIKE UPPER('%28%')

but the query still fails - now on navigation to routingNumber. Another casting will not help here because bankAccounts is a collection, and you cannot navigate from a collection in JPA without introducing a variable (ObjectDB does support navigation from collections as an extension to JPA in simple cases, but this is not a simple case).

I suggest the following:

1. As a quick workaround just to make your product work - replace this query with code that scans the collection, extracts objects and checks them. This is a common technique in applications that use NoSQL, in which complex queries are implemented as ordinary code. ObjectDB and JPA query language is much more advanced than in ordinary NoSQL databases, but still cannot cope with this kind of queries.
2. As a long term solution - adjust your model and queries to the JPA capabilities.
3. Please also shorten your package names and class names and avoid collision of class names. It is very difficult to work with such long names.

hi,

Why do we have to add the second casting? The "IndividualContactDebitorAccountFragment" has a field called "debitorAccount" with type "DebitorAccount" which by itself has a field "bankAccounts" so I don't see why we need another cast here.. (and we cannot add another one anyway in our code because it is all auto-generated).

Second thing: Can u easily extend odb to at least support simple collection navigation as in the given case as well?

Our stuff is auto generated and cannot be changed as it is now nor replaced with manual code (because we don't know what filter code the user will input)

Alex

The second casting is required because the static type of debitorAccount is DebitorAccount, which doesn't have bankAccounts as a field (only MitgliedDebitorenKonto has).

Sorry, but ObjectDB will not be extended to support this complexity in the foreseen future.

Sure it has a field named bankAccounts that's why I am curious. We have a class DebitorAccount which inherits from class Account which has a field bankAccounts.. ?

Alex

You are right, sorry. Navigation after casting is handled by special code that could not see the real type of the field when the model classes are missing (in Explorer and Server). I fixed it.

But the navigation from the collection (bankAccounts.routingNumber) is still a problem.

hi,

I'm ok with the collection for now but still.. I can not even access the debitorAccount field right now so is there a fixed version available yet?

thanks a lot!

Alex

Yes, try build 2.3.6_09.