No subject


Sun Nov 20 20:48:46 GMT 2022


```
MSSQL 'timestamp' columns are not actually timestamps, they are 8-byte blobs which store an incrementing version value whenever the row is changed, but do not actually store any date/time information whatsoever (in fact, in later versions of MSSQL they have started calling these 'RowVersion').

Currently S::L reads these as data_type => 'timestamp' but ribasushi suggested that it might be better for these to be treated as blobs since this is closer to what they actually are. He asked me to open this ticket and paste the below IRC chat log...


** scrollback from IRC **

<--snip-->
<ribasushi> vanstyn: are you certain it is a blob and it's not DBI/S::L doing switching on you? 
<vanstyn> well, navicat shows it as a BLOB ...
<vanstyn> but... that might just be how it is exposed... yeah, this seems very much like what it is... thanks!
<ribasushi> vanstyn: I'd run S::L against it to make sure - it doesn't seem to have a special handling to do timestamp => blob (by a cursory browse of source)
<ribasushi> vanstyn: but if it *is* the timestamp thing - it is rather very common, especially among .net/asp software
<vanstyn> yeah, I did run it through S::L, and it shows data_type => 'timestamp'
<ribasushi> then that's what it is ;)
<ribasushi> navicat is DWIMing for you (because it is effectively a blob)
<ribasushi> in fact...
<vanstyn> and it also set inflate_datetime => 0, which makes me think S::L knows this
* robsco (~robsco at cpc65125-nmal16-2-0-cust242.19-2.cable.virginm.net) has joined #dbix-class
<vanstyn> so, yeah, mystery solved...
<ribasushi> ilmari: ^^ perhaps S::L should s/timestamp/blob/ and shove an extra metadatakey of "was such and such datatype"
<ribasushi> ilmari: so that this confusion doesn't happen again
<ribasushi> ( for MSSQL obv. )
* stelf|pc (~stelf at 188-254-163-177.sf.ddns.bulsat.com) has joined #dbix-class
* stelf|pc_ has quit (Ping timeout: 360 seconds)
<ribasushi> vanstyn: and yes, Caelum did consider it, but added support in an ass-backwards way: https://github.com/dbsrgits/dbix-class-schema-loader/commit/81ade4d9da9b861849c51894b7e8f380e74192d4#diff-c3693ab39251ec52efb7839c3c0ca409R122
<vanstyn> ribasushi: thanks again!
<ribasushi> vanstyn: can you open a ticket against S::L with the conversation above so it doesn't get lost?
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/dbsrgits/dbix-class-schema-loader/issues/35
You are receiving this because you are subscribed to this thread.

Message ID: <dbsrgits/dbix-class-schema-loader/issues/35 at github.com>
----==_mimepart_637a92e127080_7ed7c67017250af
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p></p>
<p dir="auto">Migrated from <a href="https://rt.cpan.org/Ticket/Display.html?id=113465" rel="nofollow">rt.cpan.org#113465</a> (status was 'new')</p>
<p dir="auto">Requestors:</p>
<ul dir="auto">
<li><a href="mailto:vanstyn at cpan.org">vanstyn at cpan.org</a></li>
</ul>
<p dir="auto">From <a href="mailto:vanstyn at cpan.org">vanstyn at cpan.org</a> on 2016-03-30 22:06:35<br>
:</p>
<pre class="notranslate"><code class="notranslate">MSSQL 'timestamp' columns are not actually timestamps, they are 8-byte blobs which store an incrementing version value whenever the row is changed, but do not actually store any date/time information whatsoever (in fact, in later versions of MSSQL they have started calling these 'RowVersion').

Currently S::L reads these as data_type =&gt; 'timestamp' but ribasushi suggested that it might be better for these to be treated as blobs since this is closer to what they actually are. He asked me to open this ticket and paste the below IRC chat log...


** scrollback from IRC **

&lt;--snip--&gt;
&lt;ribasushi&gt; vanstyn: are you certain it is a blob and it's not DBI/S::L doing switching on you? 
&lt;vanstyn&gt; well, navicat shows it as a BLOB ...
&lt;vanstyn&gt; but... that might just be how it is exposed... yeah, this seems very much like what it is... thanks!
&lt;ribasushi&gt; vanstyn: I'd run S::L against it to make sure - it doesn't seem to have a special handling to do timestamp =&gt; blob (by a cursory browse of source)
&lt;ribasushi&gt; vanstyn: but if it *is* the timestamp thing - it is rather very common, especially among .net/asp software
&lt;vanstyn&gt; yeah, I did run it through S::L, and it shows data_type =&gt; 'timestamp'
&lt;ribasushi&gt; then that's what it is ;)
&lt;ribasushi&gt; navicat is DWIMing for you (because it is effectively a blob)
&lt;ribasushi&gt; in fact...
&lt;vanstyn&gt; and it also set inflate_datetime =&gt; 0, which makes me think S::L knows this
* robsco (~robsco at cpc65125-nmal16-2-0-cust242.19-2.cable.virginm.net) has joined #dbix-class
&lt;vanstyn&gt; so, yeah, mystery solved...
&lt;ribasushi&gt; ilmari: ^^ perhaps S::L should s/timestamp/blob/ and shove an extra metadatakey of "was such and such datatype"
&lt;ribasushi&gt; ilmari: so that this confusion doesn't happen again
&lt;ribasushi&gt; ( for MSSQL obv. )
* stelf|pc (~stelf at 188-254-163-177.sf.ddns.bulsat.com) has joined #dbix-class
* stelf|pc_ has quit (Ping timeout: 360 seconds)
&lt;ribasushi&gt; vanstyn: and yes, Caelum did consider it, but added support in an ass-backwards way: https://github.com/dbsrgits/dbix-class-schema-loader/commit/81ade4d9da9b861849c51894b7e8f380e74192d4#diff-c3693ab39251ec52efb7839c3c0ca409R122
&lt;vanstyn&gt; ribasushi: thanks again!
&lt;ribasushi&gt; vanstyn: can you open a ticket against S::L with the conversation above so it doesn't get lost?
</code></pre>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />Reply to this email directly, <a href="https://github.com/dbsrgits/dbix-class-schema-loader/issues/35">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AACJ4ARR5JDPXHEMCVGCXO3WJKFGDANCNFSM6AAAAAASGAVGSY">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AACJ4AWVIY56OCITRQCC2VLWJKFGDA5CNFSM6AAAAAASGAVGS2WGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFNWFQBU.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span>&lt;dbsrgits/dbix-class-schema-loader/issues/35</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/dbsrgits/dbix-class-schema-loader/issues/35",
"url": "https://github.com/dbsrgits/dbix-class-schema-loader/issues/35",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_637a92e127080_7ed7c67017250af--



More information about the DBIx-Class-Devel mailing list