search

tugberkugurlu / AspNet.Identity.RavenDB

Fully asynchronous, new and sweet ASP.NET Identity implementation for RavenDB
MIT License
42 stars 28 forks source link

Cannot query users #36

Closed wwb closed 10 years ago

wwb commented 10 years ago

In the 2.0 branch at least , using the RavenUserStore.User() method results in "System.NotSupportedException: You can't get a sync query from async session" because the session is async.

tugberkugurlu commented 10 years ago

The exception is all about what it says. You need to make your query async: http://ravendb.net/docs/client-api/working-asynchronously

wwb commented 10 years ago

Yes, that part is clear.

Now, the Identity stuff is supposed to be datastore agnostic so if you've got existing code that might expect to be able to query the IQueryable users collection you've got an issue. And if the consuming code is written in an agnostic way where you don't have ravendb's Async methods like AnyAsync() then you've got some intractable issues.

tugberkugurlu commented 10 years ago

This problem can be solved by the this library but would you like it to solve this issue for you? For example, here is the solution off the top of my head:

Now, here you have another problem: the end user can assume that we are still running identity operations async even if IDocumentSession is passed in. If you ask me, this is not something I would like to see.

IMHO, the real problem is the ravendb client. There shouldn't be a distinction like async and sync session. I am sure that there is reason behind this but from outside, this distinction seems unnecessary. Maybe @ayende can answer why those sesiion types exist separately.

ayende commented 10 years ago

The distinction is there so you wouldn't mix sync and async calls accidentally.

Oren Eini

CEO

Mobile: + 972-52-548-6969

Office: + 972-4-622-7811

Fax: + 972-153-4622-7811

On Wed, Jul 30, 2014 at 11:19 AM, Tugberk Ugurlu notifications@github.com wrote:

This problem can be solved by the this library but would you like it to solve this issue for you? For example, here is the solution off the top of my head:

  • Accept either IAsyncDocumentSession or IDocumentSession through the constructor.
  • Depending on what type of session you get, perform the operation sync or async.

Now, here you have another problem: the end user can assume that we are still running identity operations async even if IDocumentSession is passed in. If you ask me, this is not something I would like to see.

IMHO, the real problem is the ravendb client. There shouldn't be a distinction like async and sync session. I am sure that there is reason behind this but from outside, this distinction seems unnecessary. Maybe @ayende https://github.com/ayende can answer why those sesiion types exist separately.

— Reply to this email directly or view it on GitHub https://github.com/tugberkugurlu/AspNet.Identity.RavenDB/issues/36#issuecomment-50586796 .

wwb commented 10 years ago

This might be a dumb question but is there any reason not to just supply the class it's own IDocumentStore and let it manage the sessions internally? That would solve this problem as well as make things a bit easier on consumers as they don't need to start a session with optimistic concurrency. The class is already IDisposable so there are places to clean up open sessions.