FieldConvertor Enhancements

Hello,

Is it possible to get hold of the entity of the field when implementing a FieldConvertor?  I implemented a "PasswordConvertor" that hashes a string when its written to the database and returned the hashed string from the database.  It seems to be working.  In order to improve the security even further, I need to use different salts for different entities.  To do this, I need access to "salt" field of the entity when performing the conversion.  

Hope it makes sense.  

Thanks,

Werner

No, this isn't possible.  During load, we cannot guarantee which order fields would be loaded in, so if we did give your PasswordConverter an entity, the _salt field might not be set yet.  And (although this probably wouldn't be relevant to the password scenario) when a converted field is used in a query, we have to convert the comparand to its database representation (e.g. the CLR expression Where(e => e.Password == "password1") would have to be converted to WHERE Password = 'qbttxpse2'), and at that point there's no entity to pass to the converter.  Sorry!

A possible alternative is to decouple the public properties from the private fields, so your private fields -- which are what LightSpeed maps to the database -- would be the salt and the hash, but your public API would still be a Password property.  The Custom Wrappers section in http://www.mindscapehq.com/documentation/lightspeed/Working-with-Legacy-Databases/Mapping-Database-Types-to-Domain-Types discusses this approach.

Thanks Ivan.  It almost makes sense.  Assume I do the following:

public string Password

{
get { return _password; }
set
{
string p = Encode(value, salt);
Set(ref _password, value, "Password");
}
}

Then what happens behind the scenes when I do something like this?

MyUnitOfWork uow = _context.CreateUnitOfWork();
var tokens = uow.SecurityTokens.Where(token => token.Password = "password");

Based on what you said before, there is no concept of an entity and thus "password" will be sent to the database as part of the WHERE clause, not the encoded text.  Am I missing something?

Given this limitation, there is no benefit to try and encapsulate this logic within the entity.  I should also change my design not to store the salt in the same entity as the password; I can store it on the "User" entity.

Thanks,

Werner

Yes, that's right.  The docs discuss the trade-offs of custom wrappers vs. field converters, but the bad news is that custom wrappers don't play nicely with querying (they're useful for things like blobs), and field converters really need to be one-to-one.  If you have two fields, and consumers of your model need to be able to query on a combination of those two fields, you'll either need to encapsulate that query in a repository method, or put the onus on consumers to write the combined query themselves.

It would be interesting to see if your suggestions about interception attributes could help with this -- I'll try to keep it in mind!