Alex (Xtensive) wrote:

DisconnectedState itself currently doesn't allow to enumerate all the entities there, and thus there is no way to do this (but we're seriously thinking about adding this feature).

On the other hand, the data it contains is usually "pushed" into it by a set of queries performed while it was connected. So actually the simplest way show the results of some query is to:

• Perform it on server with DisconnectedState attached to the Session

• Serialize both result and DisconnectedState // a bit tricky: you must use SerializationContext to ensure Entities are serialized as references

• Deserialize DisconnectedState, attach it to some Session, and then deserialize the result on the client // a bit tricky again

• And expose the result in UI "as is".

Obviously, all this template stuff must be hidden into a single helper type handling all the dirty job. And this precisely describes serialization behavior of a sample we're working on now. Please wait for a day or so - it is almost there (we can't show half-finished thing: we fear people will start to use it almost immediately). It's easier to show the approach then to talk about it (actually, I described it for may be 4 or 5 times during last few days in Skype/email talks...).

Alex (Xtensive) wrote:

One more hint (actually, a workaround you can use now):

var all = 
  from pair in disconnectedState.Versions
  select Query.Single(pair.Key);

var animals =
  from entity in all
  let animal = entity as Animal
  where animal!=null
  select animal;

var fourLeggedAnimals =
  from animal in animals
  where animal.LegCount==4
  select animal;

Obviously, all the queries there are regular LINQ to Object queries. But in case with DisconnectedState this must be fully acceptable: it is designed to host the state of ~ 10 ... 100K of entities, but not millions. If more entities must be cached by a client, likely, you need client-side storage + sync (we'll cover this case in future as well; currently you can implement this relying only on your own forces).

xumix wrote:

DisconnectedState itself currently doesn't allow to enumerate all the entities there, and thus there is no way to do this (but we're seriously thinking about adding this feature). On the other hand, the data it contains is usually "pushed" into it by a set of queries performed while it was connected. So actually the simplest way show the results of some query is to: - Perform it on server with DisconnectedState attached to the Session

public void DsTest()
        {
            var state = new DisconnectedState();
            List<FilterEntity> suppliers = null;
            List<SampleEntity> products = null;

            using (var session = Session.Open(domain))
            {
                using (state.Attach(session))
                {
                    using (var transactionScope = Transaction.Open())
                    {
                        using (state.Connect())
                        {
                            suppliers = Query.All<FilterEntity>().Prefetch(s => s.Sample).ToList();
                            products = Query.All<SampleEntity>().Prefetch(p => p.LinkedItem).ToList();
                        }

                        var ss = Query.All<FilterEntity>().Where(f => f.NullableGuid.HasValue).Single(); // Exception {"Connection is required."}

                        transactionScope.Complete();
                    }
                }
            }
        }

So, this IS the problem, it makes DS almost unusable in our case.

Alex (Xtensive) wrote:

DisconnectedState handles pretty isolated task: it serves as fully closed state container. It isn't intended to be enumerated and queried - i.e. the associations like "it is a part of the database similar to the database itself" are wrong. It is cache with closed structure, which, being attached to Session, makes it to expose its state.

I understand why you want to enumerate it, but it's nearly the same as trying to enumerate e.g. ASP.NET cache to find the data you need. To handle this case, you must use a type wrapping both DisconnectedState and all the stuff you'd like to enumerate there, and WCF sample shows how to implement this. There is DisconnectedResult<t> type combining two parts you need together:

• DisconnectedState

• A graph of objects, which may contain references to persistent objects. E.g. there can be new CustomerFormData { Customers = List<customer>(...), Orders = new List<order>(...), ... }.

When DisconnectedResult<t>.GetValue() method is called, the following happens:

• DisconnectedState is deserialized and either attached to the current Session, or merged into already attached one there

• Graph is deserialized; since DisconnectedState is already there, DO won't hit the database while materializing any entities there; moreover, you'll see these entities in the same state as when DisconnectedResult was created.

We use classes like CustomerListResult : DisconnectedResult<list<customer>> in this sample because default WCF serializer doesn't support generic types in contracts. It seems it can deserialize generic instances only as proxies, that won't work here, because proxy doesn't have necessary logic - i.e. GetValue() method.

Alex (Xtensive) wrote:

So to summarize this:

• DisconnectedState solves a part of the problem related to the state of entities you'd like to deliver to remote party. Additionally, it gathers the changes made to remote entities.

• Another part - the list(s) of entities or something else combining them to the logical structure you need @ remote party - must be handled by some other code. We use DisconnectedResult<t> for this purpose in WCF sample, but this isn't the only way you have (btw, there are just about 20 lines of code).