One2One resolving problem

Hi,

I'm using the standard edition daily from about 3/26/09.

Sometimes when I do something like:

uow.Find<MyThing>(anId)

And MyThing has a one to one with AnotherThing Lightspeed isn't loading the AnotherThing. The AnotherThingId is set and valid but the Entity is null. By "sometimes" I mean in a pattern that I don't understand.

Also, maybe related: If  I "var myThing = new MyThing();" and then set the AnotherThingId to something valid, what is the best way to get AnotherThing loaded so that myThing.AnotherThing != null? In my situation, validating MyThing depends on AnotherThing.

Currently I do this "uow.Add(myThing);" and then check IsValid. If it fails I "uow.Remove(myThing)". This "doesn't feel right" to me.

 

Thanks

-Bert

 Hi Bert,

LightSpeed certainly should be loading the one-to-one if the returned MyThing has a non-null AnotherThingId which corresponds to a real AnotherThing in the database.  Are you able to lock this down to a reproducible scenario which you can send to us?  (We would need the two class definitions, the CREATE TABLE scripts and sample data to go in those tables.)  Thanks!

You are correct that an entity must be in a unit of work in order to resolve association IDs.  For example, if you just go:

var myThing = new MyThing();
myThing.AnotherThingId = 37;

there's no way for LightSpeed to know where to look up that 37 because myThing isn't associated with a unit of work and through it a LightSpeedContext and a connection string.  Put another way, LightSpeed doesn't know about myThing until it is Added to a UOW.

Unfortunately this does mean that doing the "Add, validate, Remove" dance is the only way if validation depends on AnotherThing.  Effectively in this scenario validation depends on the contents of the database so the entity being validated does have to be hooked up to the database even if only temporarily.  Is it possible to refactor the validation of MyThing so that it doesn't depend on fetching the associated entity from the database?

Ivan,

Thanks for the insight. I will try to trim my code down to something manageable and attach it soon.

-Bert

 Ivan,

 Here is the code. I've trimmed it down to the minimum. Also we use customized versions of the generator scripts. This stuff works most of the time.

In fact one thing I forgot to mention earlier is: after we Find<T>(id) the thing, we uow.Attach it and the AnotherThing gets resolved.

 

 

  [Serializable]
  [System.CodeDom.Compiler.GeneratedCode("LightSpeedModelGenerator VQEX", "1.0.0.0")]
  [Table("templates", IdColumnName="id", IdentityMethod=IdentityMethod.Sequence)]
  public partial class Template : Entity, ITemplate
  {
    #region Fields
  
    [Column("consumable_type_id")]
    private System.Nullable _consumableTypeId;

    #endregion
    
    #region Field attribute and view names
    
    public const string ConsumableTypeIdField = "ConsumableTypeId";

    #endregion
    
    #region Relationships

    [ReverseAssociation("Templates")]
    private readonly EntityHolder _consumableType = new EntityHolder();

    #endregion
    
    #region Properties


    public IConsumableType ConsumableType
    {
      get { return Get(_consumableType); }
      set { Set(_consumableType, value as ConsumableType); }
    }


    public System.Nullable ConsumableTypeId
    {
      get { return Get(ref _consumableTypeId); }
      set { Set(ref _consumableTypeId, value, "ConsumableTypeId"); }
    }

    #endregion
		public Entity Entity { get { return this; } }
  }
  
  [Serializable]
  [System.CodeDom.Compiler.GeneratedCode("LightSpeedModelGenerator VQEX", "1.0.0.0")]
  [Table("consumable_types", IdColumnName="id", IdentityMethod=IdentityMethod.Sequence)]
  public partial class ConsumableType : Entity, IConsumableType
  {
    #region Fields
  
    [ValidateLength(0, 256)]
    [ValidatePresence]
    [ValidateUnique]
    private string _name;
    [Column("record_version")]
    private int _recordVersion;

    #endregion
    
    #region Field attribute and view names
    
    public const string NameField = "Name";

    #endregion
    
    #region Relationships

    [ReverseAssociation("ConsumableType")]
    private readonly EntityCollection _templates = new EntityCollection();

    #endregion
    
    #region Properties

    public ICollection Templates
    {
      get { return EntityProxyCollection.Create(Get(_templates)); }
    }


    public string Name
    {
      get { return Get(ref _name); }
      set { Set(ref _name, value, "Name"); }
    }


    public int RecordVersion
    {
      get { return Get(ref _recordVersion); }
      set { Set(ref _recordVersion, value, "RecordVersion"); }
    }

    #endregion
		public Entity Entity { get { return this; } }
  }
  
  
  ///////////////////
  CREATE TABLE "CONSUMABLE_TYPES" 
   (	"ID" NUMBER(*,0), 
	"NAME" VARCHAR2(256), 
   ) ;
   
  CREATE TABLE "TEMPLATES" 
   (	"ID" NUMBER(*,0), 
	"NAME" VARCHAR2(100), 
	"CONSUMABLE_TYPE_ID" NUMBER(*,0)
   ) ;
   
  ALTER TABLE "TEMPLATES" ADD FOREIGN KEY ("CONSUMABLE_TYPE_ID")
	  REFERENCES "CONSUMABLE_TYPES" ("ID") ENABLE;   

Just a couple of quick followups:

1. Could you provide us with sample data for the CONSUMABLE_TYPES and TEMPLATES tables?  Just a few rows to reproduce the problem.

2. I notice that in these classes you have a one-to-many association rather than a one-to-one.  Can you confirm that you are still getting FK resolution issues?  In which direction -- is it when you Find a Template and then retrieve its ConsumableType property that it all goes awry?  If you could create a small console app to demonstrate exactly what entities you are loading and when, and what associations you are traversing, that would really help us zero in on the problem.

Thanks!

You're right. It's a one-many here. I'm getting my issues confused...

For this example I was getting a Template via Find<> and the ConsumableTypeId is valid but ConsumableType is null.

So far, I'm not able to reprouce this in a simple app, but I'm working on it.