I'm not sure we need to define a logical ordering of those - I'd prefer
not - I would just want to allow = as an operator on them. (We have
other things that aren't orderable, e.g., points.) We should think of
them as being kind of like points or time intervals in that sense.
On 8/19/15 11:42 PM, Heri Ramampiaro wrote:
I can look into the extension of the deep-equal so that we can use it for
ordering
lists and records, in addition to just returning a binary equality.
-heri
On Aug 20, 2015, at 12:44 AM, Mike Carey <[email protected]> wrote:
Phew! And meanwhile we should incorporate Heri's work to allow meaningful
non-atomic value comparisons and hash joining!
On Aug 19, 2015 3:39 PM, "Taewoo Kim" <[email protected]> wrote:
Sorry for my poor memory. Mike is correct. I have checked the codebase.
Byte-to-byte comparison is should be only conducted for the order by case.
For equality operations, we do have protection. If you check
AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
checks whether the given two values are comparable first. If not, it just
return false. Therefore, in this case, INT > POINT returns FALSE. The
result is FALSE, based on the fact that INT and POINT can't be compared,
not based on the byte-by-byte level comparison.
Best,
Taewoo
On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <[email protected]> wrote:
This all sounds somewhat wrong to me! It's not what I remember from
design
discussions of old... I don't think we should be doing byte by byte
comparison between disparate types. Why would users want or expect that?
Note that I'm talking about predicate cases - not internal needs like
order
by or routing of data.
On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <[email protected]
wrote:
@Steven
Index rewrite will not fire in this case, because of type mismatch.
Hence
it will fallback to non-indexed query results.
2015-08-19 11:25 GMT-07:00 Taewoo Kim <[email protected]>:
@Steven: I never tried. However, it's worthwhile to check. If the
query
semantic is correct, the optimizer will try to utilize the index
regardless
of its type. My guess is, at the end, byte-by-byte comparison will
occur.
Best,
Taewoo
On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <[email protected]>
wrote:
I think this is because the serialized versions of the list have
their
lengths among the beginning bytes, so this would make sense, since
we
don't
have a comparator for lists.
@Taewoo-What about the case of an index search? Is it okay to pass
the
wrong type to the search (which will obviously yield unknown
results)
Steven
On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
[email protected]
wrote:
Actually I observed some strange behavior while comparing
orderedLists
in
the order by clause.
Input (dataset json):
{ "a": 1i32, "b": [ 1, "hello" ] }
{ "a": 2i32, "b": [ 1, "hello" ] }
{ "a": 3i32, "b": [ 1, "hi" ] }
Query:
for $x in dataset json
order by $x.b
return $x
Result:
{ "a": 3i32, "b": [ 1, "hi" ] }
{ "a": 1i32, "b": [ 1, "hello" ] }
{ "a": 2i32, "b": [ 1, "hello" ] }
it seems the behavior is comparing by the length of the list not
the
values
themselves? is it expected?
But if I do something like this:
for $x in dataset json
order by $x.b[1]
return $x
Result:
{ "a": 1i32, "b": [ 1, "hello" ] }
{ "a": 2i32, "b": [ 1, "hello" ] }
{ "a": 3i32, "b": [ 1, "hi" ] }
On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <[email protected]>
wrote:
Sorry. The direction of inequality operator was misleading.
STRING
13
is
smaller than (<) POINT 20.
Best,
Taewoo
On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <
[email protected]
wrote:
Yes. Type conversion (casting) only happens among numeric
types
so
far.
Actually, since there is a type-tag, if you try to compare
two
non
numeric
types, it stops the comparing as soon as it sees the first
byte
from
both
side since type-tag itself has the given order (e.g., STRING
13 >
POINT
20). This is required for ORDER BY, too.
Best,
Taewoo
On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
[email protected]>
wrote:
I see, so we are technically allowed to compare anything to
anything?
Steven
On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
[email protected]>
wrote:
If there is no right comparator for the given types
(STRING
vs
POINT),
then
it does the "byte by byte" comparison.
Best,
Taewoo
On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
[email protected]
wrote:
This is currently working in master:
create type CSXType as closed {
id: int32,
csxid: string
}
create dataset CSX(CSXType) primary key id;
for $b in dataset('CSX')
where $b.id > point("3,5")
return $b;
Is this supposed to be working?
Steven
--
*Regards,*
Wail Alkowaileet
--
Best regards,
Ildar
