# character in RID is problamatic

[Gaurav Dhiman]

I am sure many users of orient must have face this challenge. Kindly suggest simplest way to handle.

Scenario:

1. Calling server function over REST

2. Server returns multiple records of a class with # in RIDs

3. Client user received RIDs to make further REST document calls, but due to # chanracter presence, calls go without RID argument

Due to # character, call to http://<<host>>:<<port>>/document/<<db>>/#RID is considered as http://<<host>>:<<port>>/document/<<db>>

Workaround:

While receiving response from server, remove all # characters from response, but this add un-required processing. It would have been better if # has not been there.

Question:

What is the significance of having # in RID ? Can't we get rid of it ? If yes, how ?

Regards,

Gaurav

[Luca Garulli]

Hi,

on REST calls all the RID on URL can be omitted.

Lvc@

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gaurav Dhiman]

On Tue, Mar 11, 2014 at 5:14 PM, Luca Garulli <l.ga...@gmail.com> wrote:

Hi,

on REST calls all the RID on URL can be omitted.

RID segment in document REST call is mandatory as per this https://github.com/orientechnologies/orientdb/wiki/OrientDB-REST#wiki-get---document. We can not omit that. Otherwise also I think # will create issues in other REST calls.

Gaurav

--

---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/IIM-qv29-ZE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

[Luca Garulli]

Sorry I meant the # can be omitted in RIDs.

Lvc@

[Gaurav Dhiman]

On Tue, Mar 11, 2014 at 5:47 PM, Luca Garulli <l.ga...@gmail.com> wrote:

Sorry I meant the # can be omitted in RIDs.

Yes, to omit that, client need to do processing of JSON received from server, which I feel is overhead for large JSON stream.

Can not we avoid # all together in JSON pushed by server.

Regards,

[Luca Garulli]

Hi Gaurav,

how would you use the returning RIDs? May you post an example here?

Lvc@

[Gaurav Dhiman]

Lets say, I get set of document RIDs from server and assign that to a JS array docs[] and later  want to fetch the specific document referring its RID using below REST call through AngularJS

$http.get('http://host:port/document/db/'+doc[i]['@rid']);

Remember, doc[i]['@rid'] will have # in it as it was received from server.

Regards,

Gaurav

[Gaurav Dhiman]

@Lvc, any pointers on this ?

How can we avoid # in JSON returned by OrientDB server ?

Regards,

Gaurav

[mgr...@gmail.com]

I think your issues deal more with the programming/framework language you are using, not an Orientdb issue.

try this search. 

REST call through AngularJS dealing with hashtags,

or this result.

http://stackoverflow.com/questions/14319967/angularjs-routing-without-the-hash

good luck.

[mgr...@gmail.com]

Personally, if I was having issues like yours I would just create my own Id's (uuid), but it's seems more of a AngularJS problem, not Orientdb.

good luck.

[Luca Garulli]

Hi Gaurav,

so why when you store the document in RAM don't you remove the # by your own? Or rather when you compose the URL just remove the first char:

$http.get('http://host:port/document/db/'+doc[i]['@rid'].substring(1));

Lvc@

--

[Gaurav Dhiman]

@Lvc, currently I am doing that way only as you suggested, but my point is why # is required at first place. What is the benefit of having # in RIDs.

Due to this #, extra processing of received JSON need to be done by client. If there is no point / benefit of having # in RIDs, why can't we get rid of it or at least replace it with some other character that do not have issues in URL.

Hope, I am able to make my point clear.

Regards,

Gaurav

[Luca Garulli]

Hi,

the reason is to recognize at the fly what's a link. This is from the first version of OrientDB, so changing it means breaking the compatibility with the past for NO REASON. Your problem is not blocking. We also use Angular.js for Studio and with a couple of lines of code you can translate #.

Lvc@

[Gaurav Dhiman]

Thanks @Lvc for explanation.

Just a thought, can we make it configurable by setting some configuration in XML file, that will make it compatible too. By default the configuration proprty can stay to #.

Well its not a priority request.

Thanks again !

Regards,

Gaurav

[Steve]

I agree with OP.  This is a problem that doesn't need to be there.  If designing OrientDB from scratch today it's likely a different char would have been chosen.  However the issue of backward compatibility is significant one so it can't be changed overnight.

Perhaps it could be staged.... In one major version (2 or 3) the api could be changed such that an RID can't be constructed using a string of form xxx#yyy but using a factory method newRid(int cluster, int index).  For string queries the replacement of '#' with the new char (say ':') could be done internally.  Then with plenty of warning and a year or so between said major version and the following major version a new char could be introduced and bring back the string constructor e.g. newRid("xxx:yyy").  Then perhaps one more major version later remove support for it in string queries.

Alternately perhaps the delimiter character could simply be an initialization parameter.  Allowing the user to choose one or other.  Defaulting to '#' for a couple of versions then switching default to ':'.

In bitcoin these kind of breaking changes are dealt with in similar ways.  There's a currently security issue that prevents certain types of transactions from being implemented safely.  The fix is easy but to avoid breaking things it will take 1-2 years to get the fix into general usage.