I think I may be missing something here...

I have a self-referencing table that creates a tree structure. For example, we'll call my table foo. Here are some columns:

foo

foo_id char(20) primary key ...other irrelevant columns one_foo_id char(20) foreign key to table foo on foo_id two_foo_id char(20) foreign key to table foo on foo_id

Everything's fine and dandy, and the code generates (and works, mostly) correctly. However, I'm having a problem with the references. When I try to go after OneFoo or TwoFoo (both properties generated that return an instance of FooEntity corresponding to the one_foo_id or two_foo_id, respectively), it doesn't check and see if it actually HAS an ID and tries to load it either way. So I can't just do if(OneFoo==null) or if(TwoFoo==null), I have to check the ID value. The problem is that the ID's are not retrieved until the entities are actually SAVED. So any time where I have to operate on the condition of whether or not I have values in OneFoo and TwoFoo, I have to stipulate that the object is current with the data in the database, which I would rather avoid.

From what I read, a weak relationship looks like it might be what I'm looking for. If that's the case, then how can I declare a relationship to be weak? If it's not the case, what CAN I do to help me out in this situation?

Thanks!

I don't know if I understand you correctly or not, but why don't you check the one_foo_id & the two_foo_id instead of checking the returned entities?

1) I guess I just sort of feel like I shouldn't have to Seriously though, I think that since null's allowed in the DB, then null should be allowed on the ORM'ed object.

2) On a more practical note, let's follow this:

1) New FooEntity is created (called foo), but not yet saved. 2) Other properties are set 3) I create another FooEntity called foo1, and yet another called foo2. 4) I set foo.OneFoo=foo1 and foo.TwoFoo=foo2 5) I am now in a situation where foo.OneFoo is NOT null and represents a legitimate FooEntity, yet foo.OneFooId=="" and foo.TwoFooId==""

AdamRobinson wrote:

1) I guess I just sort of feel like I shouldn't have to Seriously though, I think that since null's allowed in the DB, then null should be allowed on the ORM'ed object.

That's great, but not possible in .NET 1.x, unless the types of the properties are not standard types, for example an int field can't be null, as int is a valuetype, so returning 'null' from an int type is not possible in .NET 1.x and thus not in the entity classes, as we use standard .NET types, not artificial types like SqlInteger or the known Nullable types for .NET 1.x, as those won't work in databinding scenario's.

2) On a more practical note, let's follow this:

1) New FooEntity is created (called foo), but not yet saved. 2) Other properties are set 3) I create another FooEntity called foo1, and yet another called foo2. 4) I set foo.OneFoo=foo1 and foo.TwoFoo=foo2 5) I am now in a situation where foo.OneFoo is NOT null and represents a legitimate FooEntity, yet foo.OneFooId=="" and foo.TwoFooId==""

Yes, because foo1 and foo2 aren't saved yet, so the FK's aren't synchronized yet. FK synchronizing is done for you right after the PK is succesfully saved. Would foo1 and foo2 be not-new, the FKs would have been synchronized before the save, right at the moment the assignment takes place. This is by design, as an entity that's not yet saved is not defined yet, plus to have a consistent behavior for PKs which are sequenced / identity and PKs which are not sequenced.

AdamRobinson wrote:

Otis wrote:

AdamRobinson wrote:

1) I guess I just sort of feel like I shouldn't have to Seriously though, I think that since null's allowed in the DB, then null should be allowed on the ORM'ed object.

That's great, but not possible in .NET 1.x, unless the types of the properties are not standard types, for example an int field can't be null, as int is a valuetype, so returning 'null' from an int type is not possible in .NET 1.x and thus not in the entity classes, as we use standard .NET types, not artificial types like SqlInteger or the known Nullable types for .NET 1.x, as those won't work in databinding scenario's.

If we're talking about value types, then you're right. Without wrapping the value type in a reference type (which, even with generics, is always clumsy) you can't have null. However, the ORM'ed objects are reference types and reference types can be null.

2) On a more practical note, let's follow this:

1) New FooEntity is created (called foo), but not yet saved. 2) Other properties are set 3) I create another FooEntity called foo1, and yet another called foo2. 4) I set foo.OneFoo=foo1 and foo.TwoFoo=foo2 5) I am now in a situation where foo.OneFoo is NOT null and represents a legitimate FooEntity, yet foo.OneFooId=="" and foo.TwoFooId==""

Yes, because foo1 and foo2 aren't saved yet, so the FK's aren't synchronized yet. FK synchronizing is done for you right after the PK is succesfully saved. Would foo1 and foo2 be not-new, the FKs would have been synchronized before the save, right at the moment the assignment takes place. This is by design, as an entity that's not yet saved is not defined yet, plus to have a consistent behavior for PKs which are sequenced / identity and PKs which are not sequenced.

Right, and I wouldn't want or expect the PK/FK relationships to be synced up yet. I'm totally with you here.

I just think that the code generator should be smart enough to see that if his foreign key is null (which you know on the internal side of things), then he shouldn't go off and try to retrieve the object. It should be fairly trivial to do..

if((!alreadyRetrieved || forceRefetch) && !nullColumnValue)
.{
   cachedValue=GetSingleBlah();
   alreadyRetrieved=true;
.}

return cachedValue;

(.'s added to the brackets because the post was screwing up with just a bracket)

Now, of course I can do this in my entity subtype, but I guess I just don't see why I would need to write a custom property to give me what is already there.

I've removed your duplicate post, you forgot a quote tag, so that's why the post messed up.

I see your point. Determining if a field value is null wasn't a trivial task though in 1.0.2005.1 it is, which indeed could help improve the lazy loading code. I'll see how I can improve the templates with this. It's not that trivial, as a change like this can break applications, I've to see if it will break applications and if it will, I won't make the change until v2.0

If we're talking about value types, then you're write. Without wrapping the value type in a reference type (which, even with generics, is always clumsy) you can't have null. However, the ORM'ed objects are reference types and reference types can be null.

Ok, I thought you were talking about the FK fields, not the references.

By default, a new entity is returned if the lazy loading doesn't find a related entity. This was initially the case and is never changed as that would break existing code. Instead, a preference is added which controls this. If you go into the preferences of the designer, you'll find under task performers: 'LazyLoadingWithoutResultReturnsNew', which is default set to true. Set it to false, and you'll get 'null' instead of a new entity if hte lazy loading fails.

This setting is inherited by a new project, so if you already have an existing project (as you do), open the project properties as well, and set the property LazyLoadingWithoutResultReturnsNew to false there as well.

Regenerate the code and you'll now get null instead of a new entity.

Ah, thanks!