Alex (Xtensive) wrote:

About localization: that's the only reason why we're keeping http://code.google.com/p/dataobjectsdot ... tail?id=73 not closed yet. As you may find, few days ago I asked to finish this ASAP.

About length constraint: may be you're getting the exception while validation is disabled? Stack trace shows actually it is thrown by our integrated constraints (they're called constraints as well ;) ), but not by [LengthConstraint] attribute. So I suspects validation in aspect is skipped because you're in Validation.Disable() block. That's why exception type here is different.

About Xtensive.Integrity.Constraints: in near future there will be no Xtensive.Integrity at all - http://code.google.com/p/dataobjectsdot ... ail?id=488

Alex (Xtensive) wrote:

There are two different types of constraints:

• Integrated field constraints. E.g. max string\array length for a particular field, nullability for string fields... They're enforced under any circumstances, because underlying storage will not allow to violate them on persist (even temporary - i.e. until commit). These constraints are normally enforced inside XxxFieldAccessor<t>.SetValue method, that is executed to convert property value to tuple field value (column value).

• Validation constraints. These are BLL-level constraints, and they can be temporarily disabled. You may find the validation layer we have there is fully separated from Xtensive.Storage - i.e. this is a pluggable component, actually it knows nothing about Storage at all (but obviously, Storage knows about it, because it uses it). Constraints there are different: they're implemented as property level aspects integrated within common validation framework.

That's why 1st-type constraints do not involve 2nd-type: 1st are much stronger, there is no way to violate them temporarily.

So I'm not sure what to do... On one hand, you'd like to get the same exception; on another, you disable the 2nd type of constraints, so even if they would be there, you have the chance to get just an exception generated by 1st type constraint. Can you advise something here?

If you're looking for error message, may be this might help (Persistent.GetErrorMessage method code):

private static string GetErrorMessage(Exception error)
    {
      string result;
      if (error==null)
        result = string.Empty;
      else if (error is AggregateException) {
        var ae = error as AggregateException;
        var errors = ae.GetFlatExceptions();
        if (errors.Count==1)
          result = errors[0].Message;
        else
          result = ae.Message;
      }
      else 
        result = error.Message;
      return result ?? string.Empty;
    }

Alex (Xtensive) wrote:

Btw, if you won't specify the length for the string field, everything should work as you want - underlying column type will be nvarchar(max), but validation constraint will allow you to persist strings of specified length only. But I'm not sure if this is acceptable in your case.

Alex Kofman wrote:

I suggest following solution: 1. Internally cut string field value to maximum possible length before persist 2. Use field constraints in usual way

However, this approach brings some disadvantages also:

public class Person : Entity
  {
    [Field(Length = 8)]
    public string Name { get; set; }
  }

using (var transactionScope = Transaction.Open()) {

    var marco = new Person { Name = "Marco Dissel" };
    var coolProgrammers = Query<All>.Where(person => person.Name.EndsWith("Dissel"));
    // There are no cool programmers here, but at least one is expected to be :(

    transactionScope.Complete();
  }

So making this behavior optional can be partial solution of the problem. Marco, would such option help you or not?

Alex (Xtensive) wrote:

We can't move these constraints to tx.Complete():

• violation of any of these constraints indicates there is no way to persist the value at all. So basically, these constraints check if value is "persistable" at all, i.e. there will be no exception on attempt to persist it.

• DO4 must be able to persist any provided value at any moment of time. Queries, too big cached sequence of updates, etc., might lead to flush. So we assume if value is successfully set, we're able to persist it. But this does not necessarily mean it won't break validation rules, these checks are postponed so far.

v3.9 has a nice attribute: [Corrector] (or something like this ;) ). If there would be such an attribute (btw, it's pretty easy to implement it on PostSharp), the following code would solve the problem:

[Field(Length=11)]
[LengthCorrector(Max=11)]
[LengthConstraint(Max=10)]
public string Name { get; set; }

What do you think about this? Likely, Alex Kofman was talking about nearly this approach.

Alex (Xtensive) wrote:

As you see, the idea is to: a) Ensure the underlying value will fit into the storage column anyway b) Add regular validation constraint checking this.

Btw, likely, it will be simple to support of behavior like this right by [LengthConstraint(..., Truncate = true)].

Alex (Xtensive) wrote:

E.g. it can truncate "Marco Dissel" (12 chars) to "Marco Diss..." (11 chars, = 10+1). It does not matter what value to persist further, since validation constraint is anyway broken, so you won't be able to commit it. But such values looks a bit nicer in UI, if they're fetched later in the same transaction.

Alex Kofman wrote:

I've just implemented localizable error messages in property constraints. It looks like this now:

[RegexConstraint(Pattern = @"^(\(\d+\))?[-\d ]+$", 
  MessageResourceType = typeof(MyResources) , MessageResourceName = "IncorrectPhoneFormat")]
public string Phone { get; set;}

Alex Kofman wrote:

• less technical exception when using a too long string...

I've created appropriate issue: http://code.google.com/p/dataobjectsdot ... ail?id=517

First of all I plan to remove that check from field accessor, so it will not throw exception on property setting. This will help you in case you don't call Session.Persist() (i.e. execute any query) between assignment property value and performing validation.

Alex (Xtensive) wrote:

> Are there more constraints in this layer? like DateTime (sql server limitation)?

public override void SetValue(Persistent obj, FieldInfo field, T value)
    {
      if (!field.IsNullable && value==null)
        throw new InvalidOperationException(string.Format(
          Strings.ExNotNullableConstraintViolationOnFieldX, field));

      if (value!=null && field.Length > 0) {
        if (isString && field.Length < ((string) (object) value).Length)
          throw new InvalidOperationException(string.Format(
            Strings.ExLengthConstraintViolationOnFieldX, field));
        if (isByteArray && field.Length < ((byte[]) (object) value).Length)
          throw new InvalidOperationException(string.Format(
            Strings.ExLengthConstraintViolationOnFieldX, field));
      }

      EnsureGenericParameterIsValid(field);
      obj.Tuple.SetValue(field.MappingInfo.Offset, value);
    }

So for now we check just nullability & length (everything else will lead to delayed persist failure). And, as you see, constraints there aren't database specific.