Continuing with what I wrote today, I kept debugging the whole process
of instantiation and how it was affecting some parts of the logic of
my code that relies on object identity, so debugging a OneToOne
Reference I found that when it is materializing the Proxy it cannot
determine its primary key and then doesn't have a key to lookup in
the cache table, causing hence a fault and a new (unnecessary)
instantiation.
primaryKeyFrom: aDictionary
"Construct a primary key from the given parameters."
<..trimmed code..>
^self whereClause primaryKeyFromDictionary: aDictionary
And then it hits
primaryKeyFromDictionary: aDictionary
"Given a set of parameters, return a primary key suitable for
retrieving our target. Do this only if the expression is for a primary
key, and has no other conditions than the primary key one. If the
table's primary key is composite, return the array that will be needed
with the found values in the right position and nils elsewhere. (If
unreferenced primaryKey fields are nillable, this could return a
matching key. A query with other values elsewhere will throw away the
primary key, returning nil. One without will "
| left right field primaryKeyFields |
relation = #AND ifTrue:[
left := leftChild primaryKeyFromDictionary: aDictionary.
left isNil ifTrue: [^nil].
right := rightChild primaryKeyFromDictionary: aDictionary.
right isNil ifTrue: [^nil].
^self assembleCompositePrimaryKeyFrom: left and: right].
relation = #= ifFalse: [^nil].
"... continues but not for my case"
Which basically performs a lookup of the relation looking only for AND
or = relation operators, but since the lookup is performed using a
filtered type resolver, then the where clause is composed with an IN
relation and a = relation as follows:
"Base(GwParticipant).GWPARTICIPANT.type IN #('team' 'player') AND
Base(GwParticipant).GWPARTICIPANT.id =
Parameter(GWSCORECARD.participant_id)"
My gut tells me to avoid at all means hierarchical type resolvers,
since for most cases they cause more trouble than solutions, but it
goes against the reuse you get from a sound hierarchy of objects.
The alternative is to modify #primaryKeyFromDictionary: to consider
the case of FilteredTypeResolvers (and probably all resolvers except
identity ones), but since RelationExpressions doesn't know anything
about that, then it might end up dirty.
What do you suggest, do you have issues like this in other dialects?
Regards,
Esteban A. Maringolo
> --
> You received this message because you are subscribed to the Google Groups "glorp-group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
glorp-group...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/glorp-group/458ee313-2db7-4ec6-bef1-5dab9259ec08%40googlegroups.com.