UUIDs in persistence layer

Andreas Hartmann wrote:
> Michael Wechner wrote:
>> Andreas Hartmann wrote:
>>
>>> Hi Lenya devs,
>>>
>>> to sum up the recent UUID discussion:
>>>
>>> From my point of view, the next step would be
to use UUIDs to
>>> identify documents. That would mean that the
default persistence
>>> mechanism would store documents in a flat
structure which would
>>> look like this:
>>>
>>>
>>>   550e8400-e29b-11d4-a716-446655440000
>>>   550e8400-e29b-11d4-a716-446655440000.meta
>>
>>
>> is 550e8400-e29b-11d4-a716-446655440000 (without
suffix meta) the
>> actual content? I guess you are refering to the
reference to the 
>> resource,
>> right?
>
> It would be the name of the file which contains the
actual content.

I think this is exactly the problem, that a URL doesn't
have to 
correspond to exactly one resource
within a repository, be it referenced by UUID or whatever
and I think 
this is what we need to
change within Lenya

>
>
>>>   550e8400-e29b-11d4-a716-446655440231
>>>   550e8400-e29b-11d4-a716-446655440231.meta
>>>   550e8400-e29b-11d4-a716-446655443402
>>>   550e8400-e29b-11d4-a716-446655443402.meta
>>>
>>>
>>> Do you share this opinion?
>>
>>
>> if we are talking about a default persistance
manager then yes, but
>> if this would be hardcoded, then no 
>
> The question is if the persistence manager should get
any
> information apart from the UUID. If only the UUID is
provided,
> there won't be a chance to use human-readable file
names.

right, IIRC this is what Jackrabbit does and I think it's
wrong, whereas 
it might be good
practice, but I think one should give people the freedom to
make also 
use of the path
>
>
>>> If not, how do you envision the storage
structure?
>>
>>
>> I am not sure if we are confusing actual storage
with referencing?
>>
>> well, in order to show what I think how it should
be implemented I 
>> have started
>> something at http://
svn.wyona.com/repos/public/yanel/trunk
>>
>> whereas it's not quite working yet and also got
distracted on 
>> versioned published interfaces ... I have done this
because I am 
>> afraid I will never be able to explain my ideas, so
I will try to let 
>> this code speak.
>
> OK, I'll take a look at it as soon as I find the time.

no problem. I didn't mean the actual code, but rather the
ideas 
illustrated by this code 

Thanks

Michi
>
> Thanks for your reply,
>
> -- Andreas
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:
> Andreas Hartmann wrote:
>> Michael Wechner wrote:
>>> Andreas Hartmann wrote:
>>>
>>>> Hi Lenya devs,
>>>>
>>>> to sum up the recent UUID discussion:
>>>>
>>>> From my point of view, the next step would
be to use UUIDs to
>>>> identify documents. That would mean that
the default persistence
>>>> mechanism would store documents in a flat
structure which would
>>>> look like this:
>>>>
>>>>
>>>>   550e8400-e29b-11d4-a716-446655440000
>>>>   550e8400-e29b-11d4-a716-446655440000.meta
>>>
>>>
>>> is 550e8400-e29b-11d4-a716-446655440000
(without suffix meta) the
>>> actual content? I guess you are refering to the
reference to the 
>>> resource,
>>> right?
>>
>> It would be the name of the file which contains the
actual content.
> 
> I think this is exactly the problem, that a URL
doesn't have to 
> correspond to exactly one resource
> within a repository, be it referenced by UUID or
whatever and I think 
> this is what we need to
> change within Lenya

But how is this issue related with the actual content
storage?
The mapping from URLs to resources isn't subject of this
thread,
or am I getting this wrong?



>>>>   550e8400-e29b-11d4-a716-446655440231
>>>>   550e8400-e29b-11d4-a716-446655440231.meta
>>>>   550e8400-e29b-11d4-a716-446655443402
>>>>   550e8400-e29b-11d4-a716-446655443402.meta
>>>>
>>>>
>>>> Do you share this opinion?
>>>
>>>
>>> if we are talking about a default persistance
manager then yes, but
>>> if this would be hardcoded, then no 
>>
>> The question is if the persistence manager should
get any
>> information apart from the UUID. If only the UUID
is provided,
>> there won't be a chance to use human-readable file
names.
> 
> right, IIRC this is what Jackrabbit does and I think
it's wrong, whereas 
> it might be good
> practice, but I think one should give people the
freedom to make also 
> use of the path

But if you pass information which is a concern of a certain
layer
to the layers below, you lose the advantages of the layered
architecture ...


>>>> If not, how do you envision the storage
structure?
>>>
>>>
>>> I am not sure if we are confusing actual
storage with referencing?
>>>
>>> well, in order to show what I think how it
should be implemented I 
>>> have started
>>> something at http://
svn.wyona.com/repos/public/yanel/trunk
>>>
>>> whereas it's not quite working yet and also
got distracted on 
>>> versioned published interfaces ... I have done
this because I am 
>>> afraid I will never be able to explain my
ideas, so I will try to let 
>>> this code speak.
>>
>> OK, I'll take a look at it as soon as I find the
time.
> 
> no problem. I didn't mean the actual code, but rather
the ideas 
> illustrated by this code 

OK, so I hope I get the ideas by reading the code 

-- Andreas

-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org