Unexpected behaviour when (instance? (@) …) is part of the where clause.

[Rob Duda]

Within the read documentation there is mention of subclass restrictions and an example. This is actually great as it allows you to query against subclass attributes from the parent class. Here is the example from the docs:

(Telcom’read
‘(fullName)
‘(= (@ entity (instance? (@) Person) homeAddress city) “Toronto”)
‘() ‘() ‘() ‘())

As the docs state, this allows you to query through entity (defined as Entity on Telcom) and include the homeAddress attribute which is only defined on Person.

One unexpected behavior I’ve noticed though is that the query doesn’t really restrict the read to only Person. A query such as this:

(Entity’read ‘(lastName) `(like? (@ (instance? (@) amfam:som:Entrant) dlNumber) “W*”) ‘() ‘() ‘() #f)

Where amfam:som:Entrant is an Entity with the dlNumber attribute defined and mapped to the same column as dlNumber on the Person class.

This read will actually return Person and Entrant objects.

I suspect that if we had added a new column to the NJEntity table to store the dlNumber from Entrant into, that things would work as you might expect. I just don’t understand why the framework doesn’t auto-magically include the Entrant class code as part of the where clause to begin with. I would think that most would agree that this is what you would assume is happening.

0

[Owen Pond]

Hi Rob,

 

The nested instance checks are meant to be used on associations to other classes, not on the root class of the query. For the root class, you can use a non-nested instance check as it’s own clause ‘(instance? (@) amfam:som:Entrant)

Using the nested instance check can create some ambiguity. Especially in this case where to have 2 subclasses with attributes that I’m assuming don’t come from the base class. By persisting them to the same column in the DB we are breaking the assumption that they are different attributes.

 

0

[Author]

Posts