Handling of timestamp byte[8] fields

Posts   
 
    
JSobell
User
Posts: 145
Joined: 07-Jan-2006
# 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

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

where myTimestamp=0x00000864

or even

where myTimestamp=2054
daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# 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

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 Support Team
JSobell
User
Posts: 145
Joined: 07-Jan-2006
# 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.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# 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 | Lead developer LLBLGen Pro
JSobell
User
Posts: 145
Joined: 07-Jan-2006
# 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?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# 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 simple_smile ) 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 | Lead developer LLBLGen Pro