Better support for non-string identifiers (even more complex than ValueType..)

[Lars Corneliussen]

The only place where non-string-identifiers are restricted to ValueType is IDocumentSession.Load:

• ITypeConverter is not restricted to ValueType
• DocumentConvention.FindFullDocumentKeyFromNonStringIdentifiers is not restricted to ValueType
• Document.Store(object) will take the Id-Property, and run the TypeConverter - not restricted to ValueType
• IDocumentSession.Load<T>(...) has an overload for ValueType, but not for object (one problem here is backwards-compat for implicit conversions to string...)
• There are no overloads for loading many documents by non-string identifiers

We'd really like "full" support for non-string-identifiers; we'd also be willing to help coding.

[Oren Eini (Ayende Rahien)]

Can you think of any scenario where you would need non value type id?

What is the use case?

[Lars Corneliussen]

(i can't really understand why I need a good reason to "fix" a half-baked existing feature)

There is Guid, there is int, and there are many other types that potentially identify things...

But i'll try to make my concrete problem more understandable: We make heavy use of self-baked strongly-typed hierarchal IDs - which can be represented as urls. We have done some work to get good serialization support for JSON across raven, web, nsb. Whenever we have an ID, we know what it is (as long as we have the types available) and if not, we have a generic representation which we can reflect on. This makes many things simpler.

Everything is identified by those ids; also raven documents - sure we could take care of the OurId-to-ravenkey conversion ourselves, but Raven does already support non-string-identifiers - it is just half-baked.

_

Lars

[Oren Eini (Ayende Rahien)]

Guid & int are value types.

Limit ids to value types and string simplify things drastically.

And you have to understand something quite important. RavenDB does NOT support non string identifiers.

It _fakes_ that for some stuff on the client side, but honestly? We are getting too much issues related to that I regret this feature.

[Oren Eini (Ayende Rahien)]

And you can always define:

public struct OurId {

}

And use that.

[Chris Marisic]

How does an id like /user/1/manager/2/supervisor/3/executive/4 not satisfy that?

[Lars Corneliussen]

We are getting too much issues related to that I regret this feature.

Now things become clearer :-) So you'd like to withdraw support for int/guid? - just make it all strings?

Maybe a nice compromise would be to not support tag-based prefixes in combination with non-string-identifiers - what I mean is, a non-string-identifier would then be THE key - not just the last "segment" of it...

But again, currently the only place where non-string identifiers are restricted to ValueType is IDocumentSession.Load - all other places support reference types as well. So how does that simplify things drastically?

And you have to understand something quite important. RavenDB does NOT support non string identifiers.

I think I understand that. I didn't say RavenDB, I said Raven; and for me, Raven is everything that matches ´StartsWith("Raven.")´ :-) - including the client api.

[Lars Corneliussen]

Satisfy what? Asking me? Asking Ayende?

[Oren Eini (Ayende Rahien)]

inline

On Fri, Jun 1, 2012 at 12:14 AM, Lars Corneliussen <m...@lcorneliussen.de> wrote:

We are getting too much issues related to that I regret this feature.

Now things become clearer :-) So you'd like to withdraw support for int/guid? - just make it all strings?

Actually, the one place I would keep it is in the session API, elsewhere, I don't like it.

That said, it is useful in porting projects, so it probably would be there anyway.

 

Maybe a nice compromise would be to not support tag-based prefixes in combination with non-string-identifiers - what I mean is, a non-string-identifier would then be THE key - not just the last "segment" of it...

Meaningless in RavenDB. A user document with the key 1 and a customer document with the key 1 would overwrite one another.

 

But again, currently the only place where non-string identifiers are restricted to ValueType is IDocumentSession.Load - all other places support reference types as well. So how does that simplify things drastically?

Those are that way simply because it is harder to restrict, and king of pointless, too.

 

And you have to understand something quite important. RavenDB does NOT support non string identifiers.

I think I understand that. I didn't say RavenDB, I said Raven; and for me, Raven is everything that matches ´StartsWith("Raven.")´ :-) - including the client api.

Doesn't matter, the Client API can do a lot, but in the end, it is the server that rules.

[Lars Corneliussen]

inline :-)

On Thursday, May 31, 2012 11:17:30 PM UTC+2, Oren Eini wrote:

inline

On Fri, Jun 1, 2012 at 12:14 AM, Lars Corneliussen <m...@lcorneliussen.de> wrote:

We are getting too much issues related to that I regret this feature.

Now things become clearer :-) So you'd like to withdraw support for int/guid? - just make it all strings?

Actually, the one place I would keep it is in the session API, elsewhere, I don't like it.

That said, it is useful in porting projects, so it probably would be there anyway.

right.

 

 

Maybe a nice compromise would be to not support tag-based prefixes in combination with non-string-identifiers - what I mean is, a non-string-identifier would then be THE key - not just the last "segment" of it...

Meaningless in RavenDB. A user document with the key 1 and a customer document with the key 1 would overwrite one another.

Sure. In most cases you'd like the id to be scoped to the collection, hence tag...

 

 

But again, currently the only place where non-string identifiers are restricted to ValueType is IDocumentSession.Load - all other places support reference types as well. So how does that simplify things drastically?

Those are that way simply because it is harder to restrict, and king of pointless, too.

Sorry; i do still not understand how restricting to ValueType make things simpler. string -> string, not string -> via .FindFullDocumentKeyFromNonStringIdentifiers (ITypeConverter by default) - what is the problem?

 

And you have to understand something quite important. RavenDB does NOT support non string identifiers.

I think I understand that. I didn't say RavenDB, I said Raven; and for me, Raven is everything that matches ´StartsWith("Raven.")´ :-) - including the client api.

Doesn't matter, the Client API can do a lot, but in the end, it is the server that rules.

The ClientAPI is Ravens face. It matters. Else it could be in RavenContrib :)

I'm pretty sure 90+% of queries to Raven servers all over are issued through the Client API.

[Oren Eini (Ayende Rahien)]

Load(1) <-- The is obvious ValueType

Load(new OurId{ ... }) <-- this is object

Load("foo") <-- this is object? string? Can be both, either?

It result in a mess for the API, especially when you start working with dynamic API.

[Lars Corneliussen]

You do (id is/as string) in other parts of the client api already / why not also on Load(object)?

What do you mean by "dynamic API"?

[Oren Eini (Ayende Rahien)]

dynamic as in the dynamic C# api, when you are calling things dynamically.

For example:

dynamic x = "foo";

session.Load(x);

[Chris Marisic]

"We make heavy use of self-baked strongly-typed hierarchical IDs". I just expressed a heirachy as a single string /user/1/manager/2/supervisor/3/executive/4