You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Tim Reilly <ti...@consultant.com> on 2005/02/05 06:30:32 UTC

RepositoryImpl's UUID constants

I noticed this the other day (or more):

Modified:
incubator/jackrabbit/trunk/src/java/org/apache/jackrabbit/core/RepositoryImp
l.java
...
+    private static final String SYSTEM_ROOT_NODE_UUID =
"deadbeef-cafe-babe-cafe-babecafebabe";
+    private static final String VERSION_STORAGE_NODE_UUID =
"deadbeef-face-babe-cafe-babecafebabe";
+

I think real UUID's should be used. Preferably version 1 (time based.) On
one hand these would never conflict with a version 1 or version 4 uuid since
the version and variant fields appear to be invalid, but on the other hand
if a uuid implementation were going to try to validate those fields it would
cause an issue. How big of a deal would it be to change them at this point?
Maybe it's not a big a deal? Then again, if it's not too big a deal to
change...


Thanks,
-TR


Two candidate replacements if needed:
 9fbcb710-7734-11d9-914f-0010afec213c
 af5af9c0-7734-11d9-914f-0010afec213c




Re: RepositoryImpl's UUID constants

Posted by Tobias Strasser <to...@gmail.com>.
ok, we will change the hardcoded uuids to some valid ones.
cheers, tobi

On Tue, 8 Feb 2005 20:14:31 +0100, David Nuescheler
<da...@gmail.com> wrote:
> > cafecafe-00fe-1000-914f-0010afec213c
> > beefbeef-00ef-1000-914f-0010afec213c
> sounds good to me....
> 
> regards,
> david
> 
> ----------------------------------------------------------------------
> standardize your content-repository !
>                                http://www.jcp.org/en/jsr/detail?id=170
> ---------------------------------------< david.nuescheler@day.com >---
> 
> This message is a private communication. If you are not the intended
> recipient, please do not read, copy, or use it, and do not disclose it
> to others. Please notify the sender of the delivery error by replying
> to this message, and then delete it from your system. Thank you.
> 
> The sender does not assume any liability for timely, trouble free,
> complete, virus free, secure, error free or uninterrupted arrival of
> this e-mail. For verification please request a hard copy version.
> 
> mailto:david.nuescheler@day.com
> http://www.day.com
> 
> David Nuescheler
> Chief Technology Officer
> Day Software AG
> Barfuesserplatz 6 / Postfach
> 4001 Basel
> Switzerland
> 
> T  41 61 226 98 98
> F  41 61 226 98 97
> 


-- 
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Re: RepositoryImpl's UUID constants

Posted by David Nuescheler <da...@gmail.com>.
> cafecafe-00fe-1000-914f-0010afec213c
> beefbeef-00ef-1000-914f-0010afec213c
sounds good to me....

regards,
david

----------------------------------------------------------------------
standardize your content-repository !
                               http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


mailto:david.nuescheler@day.com
http://www.day.com

David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland

T  41 61 226 98 98
F  41 61 226 98 97

RE: RepositoryImpl's UUID constants

Posted by Tim Reilly <ti...@consultant.com>.
David,

> 
> > Two candidate replacements if needed:
> > 9fbcb710-7734-11d9-914f-0010afec213c
> > af5af9c0-7734-11d9-914f-0010afec213c
> i have no issue using valid uuid's but maybe we
> can use something distinctive, that could be 
> recognized by a human? something like:
> 00000000-0000-4000-0000-000000012007
> do you think that makes sense? i am not
> attached to any uuid in particular.
How about:

cafecafe-00fe-1000-914f-0010afec213c
beefbeef-00ef-1000-914f-0010afec213c

Thx,
Tim


Re: RepositoryImpl's UUID constants

Posted by David Nuescheler <da...@gmail.com>.
hi tim,

> I noticed this the other day (or more):
> +    private static final String SYSTEM_ROOT_NODE_UUID =
> "deadbeef-cafe-babe-cafe-babecafebabe";
> +    private static final String VERSION_STORAGE_NODE_UUID =
> "deadbeef-face-babe-cafe-babecafebabe";
> +
> I think real UUID's should be used. Preferably version 1 (time based.) On
> one hand these would never conflict with a version 1 or version 4 uuid since
> the version and variant fields appear to be invalid, but on the other hand
> if a uuid implementation were going to try to validate those fields it would
> cause an issue. How big of a deal would it be to change them at this point?
> Maybe it's not a big a deal? Then again, if it's not too big a deal to
> change...
the idea was that one could immediately recognize those "special
uuids" when debugging etc. while i am not sure if it makes a big 
difference whether those uuid's are in fact "real uuid's" or not, 
since i wasn't able to come up with a usecase where someone 
would validate the uuid's (but i think you are right, we should
be more careful)

> Two candidate replacements if needed:
> 9fbcb710-7734-11d9-914f-0010afec213c
> af5af9c0-7734-11d9-914f-0010afec213c
i have no issue using valid uuid's but maybe we
can use something distinctive, that could be 
recognized by a human? something like:
00000000-0000-4000-0000-000000012007
do you think that makes sense? i am not
attached to any uuid in particular.

regards,
david