Custom field mapping

Well I'm loving LightSpeed so far. For what it does, it's a very nice product. The conventions, while limiting, are actually sorta nice to provide some constraints and get you moving :).

The showstopping problem I might have run across is custom field mapping. How can I provide my own implementation of code to read/write a specific column?

Examples:

 - Use an Int64 database field to map to a TimeSpan.(Ticks)

 - Use an nvarchar(max) to object type with DataContractSerialization.

 - Map an integral type to one of my enums.

If LightSpeed doesn't do this, how do you keep your model?

The only idea I have is to make such fields private, then use partial classes to expose the right types, sticking conversion code in the property or something. The major downside here is that querying would not work right then. (Right?)

It'd be really nice if somehow I could just tell LightSpeed "hey use these two functions to convert in and out".

Thanks,
Michael

Custom conversion functions is a nice idea and one we will definitely put on the radar for v3.  (We would probably beta this via a 2.2 nightly if we do it, so if you have specific examples which are stopping you using LightSpeed on your current project then we could see if we can come up with any quick wins.)

The good news is that some of your examples actually work already.  We already provide special support for the TimeSpan type, stored as a long of ticks; and if you have an entity property of enum type then we will convert it to the underlying integer value for storage.

Regarding translating a text field to an object via deserialisation, we have done something like this in one of our projects -- basically you have a property (or just a field) as normal for the text field, then create (by hand in the partial class, if using the designer) a property for the object, the getter of which initialises the object from the backing field.  However we did use special classes for this so that setting a property of the deserialised object automatically updated the backing text field -- not so good for the general case.

For the time being, as you say, putting conversion code in the property is the way to go.  Querying runs against the backing field so it should still work except that queries will need to be expressed in terms of the underlying implementation.  For example suppose you have the following:

private int _height;  // db backing field, in cm

public Height Height {
  get { return Height.FromCentimetres(_height); }
  set { _height = value.AsCentimetres(); }
}

public struct Height {
  private int _cm;
  public static Height FromCentimetres(int cm) { ... }
  public double AsInches() { ... }
  public double AsCentimetres() { ... }
}

You would still be able to write var tallerThanBob = uow.Find<Person>(Entity.Attribute("Height") > bob.Height.AsCentimetres());, but you would not be able to write var tallerThanBob = uow.Find<Person>(Entity.Attribute("Height") > bob.Height);.  This would of course also put the kibosh on performing Height-based queries using LINQ, because LINQ would throw a type error if you tried to write Where(p => p.Height > 200).  I suspect conversion for query purposes will be the nasty bit of custom conversion functions if we do try to do these for 3.0...

OK, thanks for the quick response. I'm going to go and examine the cases we have to see if LS will work out.

Thanks!

What about enums? Is there any built-in support to map an enum to an int?

An enum gets saved as its underlying value.  For example, if you have the following enum:

  public enum Resolution
  {
    _720i,
    _720p,
    _1080i,
    _1080p
  }

Then a Resolution property value of Resolution._720p will be saved as 1, and a database value of 1 will be materialised as Resolution._720p.

You can therefore automate the mapping by specifying the corresponding database values in the enum.

If you need a custom mapping scheme, e.g. because 720p is already represented in the database as (say) 721, and you don't want to capture that in your enum (because the enum already exists, or you don't have control over it, or because you think explicit values are ugly), there's no built-in support for that at the moment.

Hey guys, nice product

About the enums - can you use them in the desiger - or do you have to "hack" the code behind - meaning that you can't use the designer anymore? 

 thanks,

 Ben

You can't currently use them in the designer, but there is a better way than hacking the generated code:

* Create a property with the desired name, and set the data type to Int32.

* Change the Generation setting of the property to None.  This tells the designer to generate no code for this property.

* Add a partial class declaration, and implement the property as your enum type in the partial class:

private Direction _direction;

public Direction Direction {
  get { return Get(_direction); }
  set { Set(ref _direction, value, "Direction"); }
}

(You don't technically need to do the first two steps, because you can always add your own fields through the partial class without needing to mention them in the designer.  The advantages of having a field in the designer are (a) it's more visible to someone maintaining the model through the designer and (b) it means the field can take part in schema round-tripping, i.e. the designer will create a column for it if you do an Update Database, or will not try to recreate it if you do an Update From Source.)

great thanks Ivan,

 that is pretty much all I was looking for - I was already doing the partial class thing, but didn't realise I could set the code generation to none and get the field automatically in the db as well

cheers