Different byte order (?) when importing SQL Server UUID

[matthenning]

I get strange results when using Uuid::import on a uuid returned from an SQL Server uniqueidentifier filled by the SQL default newsequentialid() like this:

>>> $uid = Webpatser\Uuid\Uuid::import(App\Deployment::first()->id)
=> Webpatser\Uuid\Uuid {#742}

>>> dd($uid)
Webpatser\Uuid\Uuid {#742
  #bytes: b"""
    k\x07[‚ìD\x11å€Ü\x00\x15]\n
    ¼T
    """
  #hex: null
  #string: "6b075b82-ec44-11e5-80dc-00155d0abc54"
  #urn: null
  #version: null
  #variant: null
  #node: null
  #time: null
}

>>> App\Deployment::find($uid->string)
=> null

The last bit should have returned the model, from which I previously got the uuid.
The actual uuid as I see it in SQL Server Management Studio looks like this though:

SQL: 825B076B-44EC-E511-80DC-00155D0ABC54
PHP: 6B075B82-EC44-11E5-80DC-00155D0ABC54

The first two blocks seem to be in reversed order.

When using the first uuid I can find the model as expected:

>>> App\Deployment::find('825B076B-44EC-E511-80DC-00155D0ABC54')
=> App\Deployment {#734}

Am I missing something here?

[webpatser]

hmmm.. I don't have an SQLServer instance available. So it's hard to figure out why this is happening.

Maybe someone can track what is happening?

[matthenning]

I've since given up on the issue but I was able to figure out it has something to do with SQL Server storing the UUID in little or big endian.
I hope this helps someone.

[olavivaino]

Theres a blog post explaining this endian-issue: https://blogs.msdn.microsoft.com/openspecification/2013/10/08/guids-and-endianness-endi-an-ne-ssinguid-or-idne-na-en-ssinguid/