Hello:

I was thinking of representing non set foreign key values of Entities as Null Objects, with a corresponding id value of 0 in the database, and having the database field schema as "not null" so that inner joins can be done on database queries.

Is this supported in llblgen pro? Is there a way to implement this so that there is a Entity.Null subclass generated for each Entity class, and the databinding, and add/update coding in the framework will recognize this?

Or would the gains not be worth the trade off in custom coding?

Sincerely, Matt

erm.... databases already support the concept of 'not set': NULL. So make your FK fields nullable in the DB, and generate the field as a nullable type, done

I think Matt means returning an instance of a NullCustomer object if the customer FK is null. Not a null value.

I would say this functionality is specific to the project. This topic has been approached in other ORM tools. There response is the use an adapter. here it's TypeConverter with NHibernate it's IUserType.

Yes, by "Null Object" I mean the pattern.. the NullCustomer concept above where it is a static instance.

class Customer { .... regular class definition here ...

    public readonly static Customer Null = new NullCustomer();

    internal class NullCustomer : Customer 
    {
         // do nothing methods for business logic
    }

}

Ah! Sorry for my misinterpretation of the subject!

So your FK field is of type T, and NullCustomer is a derived type of T? Otherwise you won't be able to return a NullCustomer object from the CustomerId field in say Order. In this case, you could use a typeconverter.

LLBLGen Pro explicitly uses FK fields in entities. If an O/R mapper doesn't do that, it needs a container for the FK field, e.g. : myOrder.Customer.CustomerId, where the instance of 'Customer' here can be a nullcustomer because the CustomerId isn't set.

Is this what you're after?

I still don't fully grasp what your end goal is with all this, as it looks to me that this code isn't really helping making things less complex.

It looks like you're trying to achieve that you don't have to deal with a null valued int typed field, which is what's done with nullable fields which aren't supposed to be generated as a nullable field: if you read such a field, e.g. an int field, the entity will return 0 or the default value for the field.

You can also do a check in for example DataAccessAdapter.OnBeforeEntitySave, where you check whether an entity has nulled FK fields (by traversing its Fields collection) and if so, set the field to a default value. The field is then saved.

Otis wrote:

It looks like you're trying to achieve that you don't have to deal with a null valued int typed field, which is what's done with nullable fields which aren't supposed to be generated as a nullable field: if you read such a field, e.g. an int field, the entity will return 0 or the default value for the field.

I would like to piggyback on this thread, as I'm attempting to migrate to 2.6 from 1.0.2004.2 Final August 5, 2005 version.

In version 1, I'm getting the behavior you mentioned above (i.e. if a null is in the database on an int column, I get a 0 back when I say clientClass.myint = entityClass.myint; )

In my migration tests though, I get back a nulll, which of course throws an exception. My question is: how do I get 2.6 to behave the same as 1.0.2004.2 in regards to nulls?

Thanks

Take a look at the answers in the following thread.

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=14601

Also, please don't hijack threads as there is no guarantee that we'll see your question