From: Joe W. <jo...@gm...> - 2012-12-30 01:24:24
|
Adam and Wolfgang, Fascinating discussion. I always enjoy learning about how eXist-db works under the hood. So many optimization that are there to help our queries run quickly and efficiently. Adam - I'd love to know more about how you tracked this down. The idea to add handling for this case sounds good. Thanks, Joe Sent from my iPhone On Saturday, December 29, 2012 at 10:46 AM, Wolfgang Meier wrote: > > Basically the outer xs:string uses the CastExpression class in eXist, > > and at compilation time it needs to understand what the possible type > > of the evaluated if/else expression could be. As such it gets the type > > of the result of the 'then' branch of the if expression, and also get > > the type of the result of the 'else' branch of the if expression. It > > then tries to find a super-type of these two types > > (Type.getCommonSuperType(x, y) in eXist Java code). > > > > > Correct. Expression.returnsType is called to make a "best guess" of the possible return type of an expression. This is not always possible though (due to a lack of static type information), in which case Type.ITEM is returned. > > The important point here is that returnsType should return a specific type like Type.NODE, if and only if we can be sure both clauses of the if...then...else return nodes. In this case the optimizer may choose a different evaluation strategy. On the other hand, if Type.ITEM is returned, the query engine should not make any assumption about the type of the sequence to be expected. The optimizer interprets Type.ITEM as: it's not possible to determine the correct type. > > I would expect eXist to correctly process expressions returning empty() despite the warning in the logs. I actually think the EMPTY case should be handled by Type.getSuperType instead of printing a warning. I will check this. > > Wolfgang |