Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Handling of timestamp byte[8] fields
 

Pages: 1
LLBLGen Pro Runtime Framework
Handling of timestamp byte[8] fields
Page:1/1 

  Print all messages in this thread  
Poster Message
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 11-Jan-2018 05:13:21.  
I have a situation where I'm using a timestamp to track updates to a row, but I need to send the timestamp to a client, then when they request the data again the timestamp is included to avoid returning unchanged information.
Now I can take the existing value, and perform something like
Code:
BitConverter.ToInt64(data.Timestamp.Reverse().ToArray(), 0)

This gives me the timestamp as a long, but when I want to include that value in a request it's a bit messy having to throw it back and forth into byte arrays.
Is there any built-in functionality for returning timestamp fields as unsigned longs? I'd prefer to avoid having to write and maintain typeconverters in the designer and runtimes.
SQL supports a timestamp column as a number, so you can say
Code:
where myTimestamp=0x00000864

or even
Code:
where myTimestamp=2054

  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8110 posts
# Posted on: 11-Jan-2018 07:29:08.  
JSobell wrote:
I have a situation where I'm using a timestamp to track updates to a row, but I need to send the timestamp to a client, then when they request the data again the timestamp is included to avoid returning unchanged information.

Are you doing this because you want some kind of concurrency control over updates? Have you already tried LLBLGen Concurrency Control?

JSobell wrote:
Now I can take the existing value, and perform something like
Code:
BitConverter.ToInt64(data.Timestamp.Reverse().ToArray(), 0)

Is there any special reason why you are doing this conversion?

JSobell wrote:
Is there any built-in functionality for returning timestamp fields as unsigned longs? I'd prefer to avoid having to write and maintain typeconverters in the designer and runtimes

Too bad you don't want a TypeConverter because it seems that is the best way to go here. A TypeConverter is not too hard to code and to maintain.


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 15-Jan-2018 08:20:08.  
No, I'm doing this because a performance data retrieval process involves including the timestamp to a query to avoid fetching unchanged data.
A typeconverter isn't the best solution here, as SQL server has native support for conversion of timestamps to numeric fields, so returning the numeric value doesn't require any code based conversion.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37880 posts
# Posted on: 15-Jan-2018 10:34:14.  
The entity field type is required to match the type of the field it's mapped on. This means that if you want to have it as a long, the type of the field has to be a long too, there's no built-in 'implicit conversion' defined between byte array and long for mappings.

One thing you could do is create a computed column in the table which converts the timestamp column to a long and map that instead. the timestamp field isn't to be written anyway so you don't lose functionality because of this. you do have an extra column in the table for this purpose but it's either that or a typeconverter. The main problem is reading the data: the value from the timestamp column is of byte[8], and converting that to a long won't work without extra code (hence a typeconverter) at the .net level.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 15-Jan-2018 12:14:39.  
OK. We've found using typeconverters to be a real pain though, as it means creating and maintaining additional projects to build and keep in sync any information (such as enums) that are required at design time, so it becomes a chain of compile, package, deploy, import to source folder of another project, reference from LLBLGen5 config file... and this is all just in design time.

It might be nice if the LLBLGen designer was able to load the converters from a Nuget package too. Since they are also typically going to be loaded by the resultant runtime using nuget, does it make sense both systems source it from the same service?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37880 posts
# Posted on: 17-Jan-2018 10:22:32.  
Though loading a file from a nuget package requires the file on disk in the real folder. This is a problem, as it relates to the sln file's folder. Or do you suggest the package has to be pulled again from nuget by the designer?

That might work, though updating the typeconverter is then even more tedious I think than it currently is or do you push to a local nuget source? (just trying to get a clear view of what your use case is Regular Smiley) What it should do to solve it IMHO is to copy the file first and then load the type converter. Currently it simply reflects over the assembly (for reflection only but still...) and this locks the file.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.