Using AutoPersistenceModel, how do I set a not null convention?

[Anders]

Hi,

I want almost all of my properties to be "non-null", and instead
override some specific properties that can be null. How do I do this
using AutoPersistenceModel?

Thanks

[James Gregory]

You want a property convention to set everything to null, then you have a few options for how to handle the not null ones.

something like:

public class NullPropertyConvention : IPropertyConvention

{

  public bool Accept(IProperty target)

  {

    return true;

  }

  public void Apply(IProperty target)

  {

    target.Nullable();

  }
}

then for the not nulls, you can either override them on the AutoPersistenceModel :

.ForTypesThatDeriveFrom<MyEntity>(m =>

  m.Map(x => x.MyProperty)

    .Not.Nullable());

or you can use an automapping override:

public class PersonMappingOverride : IAutoMappingOverride<Person>  
{  
  public void Override(AutoMap<Person> mapping)  
  {

    mapping.Map(x => x.MyProperty)

      .Not.Nullable();
  }  
} 

[Anders]

Thanks for the hint in the right direction, however it seems like the
convention is overriding my "manual" overrides.


public class NotNullPropertyConvention : IPropertyConvention

{
public bool Accept(IProperty target)
{
return true;
}
public void Apply(IProperty target)
{

target.Not.Nullable();
}
}

.ConventionDiscovery.Add<NotNullPropertyConvention>()

.ForTypesThatDeriveFrom<Participant>(map =>
{
map.Map(x => x.BarCode).Nullable();
map.Map(x => x.Country).Nullable();
map.Map(x => x.Title).Nullable();
})

The Participant-table gets not null on all properties including
BarCode, Country and Title.

This feels odd, or am I doing something strange?

On Mar 25, 3:52 pm, James Gregory <jagregory....@gmail.com> wrote:
> You want a property

> convention<http://wiki.fluentnhibernate.org/show/Conventions>to set

> everything to null, then you have a few options for how to handle the
> not null ones.
> something like:
>
> public class NullPropertyConvention : IPropertyConvention
> {
>   public bool Accept(IProperty target)
>   {
>     return true;
>   }
>
>   public void Apply(IProperty target)
>   {
>     target.Nullable();
>   }
>
> }
>
> then for the not nulls, you can either override them on the

> AutoPersistenceModel<http://wiki.fluentnhibernate.org/show/AutoMappingAlteringEntities>
>  :

>
> .ForTypesThatDeriveFrom<MyEntity>(m =>
>   m.Map(x => x.MyProperty)
>     .Not.Nullable());
>
> or you can use an automapping

> override<http://wiki.fluentnhibernate.org/show/AutoMappingOverrides>
> :

[James Gregory]

Hmm. Update your Accept method to do this:

return !target.HasAttribute("not-null");

That means it'll only apply it to any classes that haven't already had it set.

[Anders]

target.HasAttribute("not-null") always returns false both in Accept
and Apply, I created a ugly workaround by setting not-null explicitly.

I'll try to create a small sample (showing the odd behavior) in a
couple of hours.

[Paul Batum]

James,

I am anticpating that we are going to run into quite a few problems like this one, because the fluent interface is designed for specifying values rather than querying them. For example, we have code that sets things using AddAlteration() - those settings won't be applied by the time the Accept() method is called will they? Furthermore some settings are held in different places - in the case of Nullable, it writes to the column properties, while HasAttribute checks the extended properties.

What are your thoughts on how this should be tackled, both short term and long term (semantic model)?

Paul Batum

[James Gregory]

Short term: Get rid of the AddAlteration stuff, they're barely used and when they are they just surprise us with situations like this. It's a reasonable idea, but without it being implemented across the board it just leads to confusion.

Longer term: I actually started refactoring this stuff out but it never went anywhere at the time. My original idea was to have an extra interface that wraps the individual parts, which'd expose information for querying purposes. Something like IProperty and IPropertyInterrogator. Half of the methods already have public getters for what they're setting anyway, so I was going to extract these into that interface (and flesh out the missing ones), and then that interface would be exposed through the conventions instead of the standard one. Two birds: conventions get the extra info they need for querying, and the FI loses all the read properties that aren't needed.

That was my original thinking for trunk anyway, I don't know if it's best for SM. Perhaps it is, perhaps it isn't.