Incorrect RavenDB OneTimeToken query
ben-jacobs opened this issue · comments
I bet you hate seeing all these new bug reports from me.
In relation to log error:
[19:23:11 Error] Aguacongas.IdentityServer.Admin.Services.TokenCleanerHost
Exception removing expired grants: Raven.Server.Documents.Queries.Parser.QueryParser+ParseException: 2:25 Expected end of query but got: -03-29T21:53:11.0026085Z
In your RQL functions (e.g. for OneTimeToken cleanup), you need to wrap dateTime in quotes e.g.
from OneTimeTokens where Expiration < 2021-03-29T21:53:11.0026085Z order by CreatedAt
becomes
from OneTimeTokens where Expiration < "2021-03-29T21:53:11.0026085Z" order by CreatedAt
ISO8601 dates are sorted lexicographically provided they are in the same timezone (these all appear to be UTC).
By the way, the RavenDB models aren't really modelled in the "document db" way ... it's more like a relational model dropped into RavenDB. This tends to pollute the collections quite a bit (e.g. my RavenDB collections against IdentityServer2 were only about 6 different collections from memory). It'd be good to prefix the class names with a common prefix (using a DocumentStore convention if you can't change the class names) e.g. TheIdSrvCOLLECTION.
store.Conventions.FindCollectionName = type => { if (typeof(Client).IsAssignableFrom(type)) return "TheIdSrv"+DocumentConventions.DefaultGetCollectionName(type); return DocumentConventions.DefaultGetCollectionName(type); };
Of course this does have flow on consequences for queries etc, particularly given that you are building them via strings rather than using DocumentQuery etc.
@ben-jacobs :-D no I don't. I like people contributing to open source, and you are really helpful to me.
Yes, the RavenDb models is not modelled in a "no SQL way" to be easier to map from relational model using OData like request and be able to handle expand instructions. So it's why I've to design the document store like this.
Can you open a new enhancement for the collection prefix please ?
I get why you've done it the way you have and no complaints from me :)
The collection prefix is kind of a middle-ground to separate concerns at the database level (e.g. one of your collection names collided with one of my existing ones).
Will do an enhancement request (I think the most complex bit of that will be in resolving the collection names when you're building up the query string).
As always, you've made a great project that really tries to simplify what can be a VERY frustrating part of app development - I've been using IdSrv (mainly 2) for over 5 years, and I always cringe when I have to touch my codebase relating to identity.