I've read on the Roadmap page about a new upcoming binary GUID datatype on version 2.13. Could anybody can explain me what this is about and what to expect? (Better index performance/more efficiente storage..)

regards,
Mario

Mario,

<<
I've read on the Roadmap page about a new upcoming binary GUID datatype on version 2.13. Could anybody can explain me what this is about and what to expect? (Better index performance/more efficiente storage..)
>>

Not sure of exact reasons for doing this but i would guess same reasons you listed:
- 16 byte storage instead of 38
- index and joins should benefit from both smaller key (for storage and comparison) as well as binary comparison (no text comparison considerations)
- native MS guid compatibility (might be of more benefit for .net side)

Raul

Mario,

<< I've read on the Roadmap page about a new upcoming binary GUID datatype
on version 2.13. Could anybody can explain me what this is about and what to
expect? (Better index performance/more efficiente storage..) >>

The benefits are pretty much what you say: less storage, more efficient
comparisons.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

We're about to begin development this week and rely heavily on GUIDs for primary keys, using EDB GUID datatype.

I would like to know if there are any consideration we could take in order to migrate to the new binary datatype as painless as possible.

Development is done with Delphi.


regards
Mario,

>The benefits are pretty much what you say: less storage, more efficient
comparisons.<

Tim,
    Will the resolution be the same as with the current text GUID? (Same probability of collisions?)

Barry

Barry,

<< Will the resolution be the same as with the current text GUID? (Same
probability of collisions?) >>

Yes, exactly the same.  The only difference is that it won't be converted
into text.

Tim Young
Elevate Software
www.elevatesoft.com

Mario,

<< I would like to know if there are any consideration we could take in
order to migrate to the new binary datatype as painless as possible. >>

The only difference will be the Delphi TField type - the binary GUID will
use a TBytesField instead of a TGUIDField (descended from TStringField).
Unfortunately, there is no Delphi TField descendant for binary GUIDs.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Thanks for the heads up!

TByteField is the issue I was worried about, since we work with persistent fields switching from TGUIDField to TBytesField could get time consuming.

BTW, if it is ok with you, I'll be glad to be a Beta tester for this feature, son we can implemented this functionality in our app from the beginning.

regards,
Mario

"Tim Young [Elevate Software]" wrote:

Mario,

<< I would like to know if there are any consideration we could take in
order to migrate to the new binary datatype as painless as possible. >>

The only difference will be the Delphi TField type - the binary GUID will
use a TBytesField instead of a TGUIDField (descended from TStringField).
Unfortunately, there is no Delphi TField descendant for binary GUIDs.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Mario,

<< BTW, if it is ok with you, I'll be glad to be a Beta tester for this
feature, son we can implemented this functionality in our app from the
beginning. >>

It's actually almost done, but I'll have to revisit why it wasn't completed.
Many of these features that are on the roadmap have been, at least, started
or mostly completed in the engine but have been delayed due to one or more
nagging roadblocks to completion.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Are you planning to surface an ability to query this directly using SQL
? (would need some text to binary conversion/cast functions or ability
to specify hex valued for binary).

Raul


On 1/17/2013 11:50 AM, Tim Young [Elevate Software] wrote:
> It's actually almost done, but I'll have to revisit why it wasn't
> completed. Many of these features that are on the roadmap have been, at
> least, started or mostly completed in the engine but have been delayed
> due to one or more nagging roadblocks to completion.