Re: UUID query ignores characters 33 to n.... didn't know that!

2018-09-03 Thread Paul Lovejoy via 4D_Tech
When I first saw 4D’s requirement for unique indexes I was tempted to replace 
other ids in our databases with UUIDs in order to save space ... I quickly gave 
up on that idea. I just let 4D manage UUIDs to have unique IDs for backup and 
journalizing functions and I don’t assume anything regarding those fields and 
indexes. 

Paul 

> On 3 Sep 2018, at 21:07, Jim Labos - infobase via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> Yes thanks, that is what I became aware of at that point. Previously UUID's
> nature was not particularly interesting to me and so I thought of it as
> Alpha numeric string. For comparison's sake a text will work but not as I
> previously falsely assumed.
> 
> This old dog can still learn!
> 
> Cheers
> 
> Jim Labos - infobase
> 
> 
> 
> -
> Jim Labos - infobase
> --
> Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: UUID query ignores characters 33 to n.... didn't know that!

2018-09-03 Thread Jim Labos - infobase via 4D_Tech
Yes thanks, that is what I became aware of at that point. Previously UUID's
nature was not particularly interesting to me and so I thought of it as
Alpha numeric string. For comparison's sake a text will work but not as I
previously falsely assumed.

This old dog can still learn!

Cheers

Jim Labos - infobase



-
Jim Labos - infobase
--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: UUID query ignores characters 33 to n.... didn't know that!

2018-09-03 Thread Arnaud de Montard via 4D_Tech

> Le 3 sept. 2018 à 00:45, Jim Labos - infobase via 4D_Tech 
> <4d_tech@lists.4d.com> a écrit :
> 
> [...]
> 
> What do you all think? Is this a bug? An annoying gotcha? Did you already
> all know this and I am the only one who didn't?

QUERY([aTable];[aTable]longint=Num("123xxx")
We are not surprised that values = 123 are found. If you consider that 4D uuid 
field is a 2^128 integer (scalar number), it's the same thing that happens to 
your trailing "xxx" and those above. 

BTW, I think that uuid fields with an alpha icon in structure it is a source of 
confusion. 

-- 
Arnaud de Montard 



**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: UUID query ignores characters 33 to n.... didn't know that!

2018-09-02 Thread Keisuke Miyako via 4D_Tech
it's not that "query ignores characters",
it has more to do with how string-to-uuid conversion works.

to understand how it works, create a UUID field, create a record, assign a 
value.

e.g.

CREATE RECORD([Table_1])
[Table_1]Field_2:="www"

you will notice that Field_2 which is a UUID,
evaluates as 7720202020202020202020202020 in the debugger.

another example

[Table_1]Field_2:="abcd"
61626364202020202020202020202020

but

[Table_1]Field_2:="abcdabcdabcdabcdabcdabcdabcdabcd"
ABCDABCDABCDABCDABCDABCDABCDABCD

so if the string isn't a 32-digit hex,
it is first transformed to look like one (UTF-8 character code, padding by 
spaces).

then it is evaluates as integer (UUID).

then it is converted back to string for display (hence the uppercase).





**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

UUID query ignores characters 33 to n.... didn't know that!

2018-09-02 Thread Jim Labos - infobase via 4D_Tech
Mac OS Yosemite, 4D v15.6

If I am querying a UUID field, I use a UUID var of course. However there is
no UUID variable type so like everyone I use a text var. What I never
noticed before as I didn't need to check, is that *if* the var itself
contains the UUID in the first 32 characters but has extra characters after
it then 4D still finds a match!

So let's say the value in the UUID field's value is
607BFEA7CE2244EB9B00C2330E4E32F5

if my var $txt_UUID:="607BFEA7CE2244EB9B00C2330E4E32F5"+"xxx"

Query([table1];[table1]UUID_FIELD=$txt_UUID)

will still find the record.

So in this case
607BFEA7CE2244EB9B00C2330E4E32F5"=607BFEA7CE2244EB9B00C2330E4E32F5xxx"

I don't think this is a bug as 4D is using a special format for the UUID.
However I falsely assumed that you needed an exact match for that type of
query but it seems not.

What do you all think? Is this a bug? An annoying gotcha? Did you already
all know this and I am the only one who didn't?

Cheers

Jim Labos - infobase



-
Jim Labos - infobase
--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**