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.
On 18/03/14 22:59, Gaurav Dhiman wrote:
> 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
>
>
>
> On Friday, March 14, 2014 5:39:06 PM UTC+5:30, Lvc@ wrote:
>
> 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@
>
>
>
> On 14 March 2014 16:47, Gaurav Dhiman <[email protected]
> <javascript:>> wrote:
>
> @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
>
>
> On Friday, March 14, 2014 8:40:36 AM UTC+5:30, Lvc@ wrote:
>
> 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@
>
>
>
> On 14 March 2014 06:29, <[email protected]> wrote:
>
> 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.
>
>
>
> On Tuesday, March 11, 2014 6:31:04 AM UTC-5, Gaurav
> Dhiman wrote:
>
> 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
>
> --
>
> ---
> 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
> [email protected].
>
> For more options, visit
> https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
>
> ---
> 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 [email protected]
> <javascript:>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
>
> ---
> 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 [email protected]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
