I have a application that is DO 3.9 and want to start extending it using DO 4.

To do this I need a couple of shared object's , that exist in both DO 3.9 and 4.

My site obect is in 3.9 so I created it in 4 and update any changes on the 3.9 version to the 4 version.

Simple version of objects:

public abstract class Site : DataObject {

       public abstract String name(get; set;}
       public abstract long D4Id(get; set;} // set to d4 id when created.

        [ItemType(typeof(PostCode))]
    public abstract DataObjectCollection PostCodes {get;}

       public virtual void RemovePostCode(PostCode postcode) {
                PostCodes.Remove(postcode);
                Model.Config.Site.D4RemovePostCode(D4Id, postcode.D4Id);
        }

}

&

[HierarchyRoot]
public class Site : Entity {
        [Field, Key]
        public long Id { get; private set; }
        [Field]
        public string Name { get; set; }

        [Field]
        public EntitySet<PostCode> PostCodes { get; private set; }

        public static void D4RemovePostCode(long targetId, long pcId) {
            using (D4.domain.OpenSession()) {
                using (var transactionScope = Transaction.Open()) {
                    Site target = (Key.Create<Site>(Tuple.Create(targetId))).Resolve<Site>();
                    PostCode pc = (Key.Create<PostCode>(Tuple.Create(pcId))).Resolve<PostCode>();
                    target.PostCodes.Remove(pc); *****  Exception thrown.
                    transactionScope.Complete();
                }
            }
        }
}

I use OnPropertyChanged to replicate changes of the value fields to the V4 objects. and add/remove from entityset when there is an add/remove on the DataObjectCollection. All works ok except Remove on the entity set, a call toD4RemovePostCode from RemovePostCode this throws the following exception:

Message "Method not found: 'Void Xtensive.Storage.Internals.EntitySetItem2..ctor(Xtensive.Storage.EntityState, Boolean)'." Source "Xtensive.TypeHelper.GeneratedTypes" StackTrace " at NNet.Model.Config.EntitySetItems.n_c_Site-PostCodes-n_c_PostCode..ctor(EntityState , Boolean ) at NNet.Model.Config.EntitySetItems.n_c_Site-PostCodes-n_c_PostCode.~Xtensive.Core.Aspects.ProtectedConstructorAccessor(EntityState , Boolean ) at Xtensive.Storage.Internals.Activator.CreateEntity(Type type, EntityState state, Boolean notify)\r\n at Xtensive.Storage.EntityState.get_Entity() at Xtensive.Storage.Key.Resolve(Session session) at Xtensive.Storage.Key.Resolve()\r\n at Xtensive.Storage.EntitySetBase.Remove(Entity item, Boolean notify) at Xtensive.Storage.EntitySet1.Remove(TItem item) at NNet.Model.Config.Site.D4RemovePostCode(Int64 targetId, Int64 pcId) in D:\Project\NNet-Web\NNet\Config\Model\Site.cs:line 284 at NNet.Config.Site.RemovePostCode(PostCode postcode) in D:\Project\NNet-Web\NNet\Config\Site.cs:line 337" string

If I perform the same operations in just D4 then remove works fine.

Tony Steele NeighbourNet Ltd

This thread was imported from our support forum. The original discussion may contain more detailed answer. Original topic by Anonymous.

asked Jul 21 '09 at 23:55

Editor's gravatar image

Editor
46154156157


One Answer:

Alex (Xtensive) wrote:

What build of DO4 you're using? If latest nightly, there is a bug with key caching, and we're working on it. Briefly, we've made a good performance optimization related to internal Key object representation, but there is a serious mistake now. It will be fixed today, and we'll update nightly build immediately.

Issue: http://code.google.com/p/dataobjectsdot ... ail?id=299


Alex (Xtensive) wrote:

Just looked up the stack trace - it seems there is a different problem. I've just created an issue for it: http://code.google.com/p/dataobjectsdot ... ail?id=301


Alex Kofman wrote:

Just a little tip: Method Key.Resolve(tuple) become obsolete now. Use Query.Resolve() instead.

Key.Create<Site>(Tuple.Create(targetId)).Resolve<Site>()

Will be transformed to:

Query<Site>.Resolve(targetId)

Alex (Xtensive) wrote:

I can explain the reasons:

  • Key.Resolve is not an obvious thing, although it makes key resolution construction very short. It may return null, which is actually a possible source of mistakes.

  • Query.Single seems much more obvious, although it makes the code a bit longer. Single may not return null - it will throw an exception if there is no Entity corresponding to the key.

So there will be both Single & SingleOrDefault, as in LINQ.

Issue: http://code.google.com/p/dataobjectsdot ... ail?id=229

answered Jul 22 '09 at 03:16

Editor's gravatar image

Editor
46154156157

Likely, there will be other changes. We're thinking about renaming it to Query.Single.

(Jul 22 '09 at 03:16) Alex Yakunin Alex%20Yakunin's gravatar image

Anonymous wrote: Thanks for the tip, the method seemed a bit long winded, but the only way I could find in examples.

Will try the next nightly build just in case.

Tony

(Jul 22 '09 at 03:16) Editor Editor's gravatar image

Anonymous wrote: Just to confirm - my remove problem is fixed

(Jul 22 '09 at 03:16) Editor Editor's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×573

Asked: Jul 21 '09 at 23:55

Seen: 3,186 times

Last updated: Jul 21 '09 at 23:55

powered by OSQA