You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/06/12 17:28:55 UTC
[1.4] UUIDs in persistence layer (was: Re: Human-readable UUIDs,
languages in UUIDs)
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
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 not, how do you envision the storage structure?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>> 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.
>
> BTW, if you consider these ideas valuable for 1.4, IMO it would be
> nice if you could post a summary so that the community gets an
> overview without examining the code. WDYT?
sure. Will try to do this shortly. For the moment one could say it's
from an architecture POV about
- versioned published interfaces (although Java doesn't provide this I
think one can implement it as a workaround)
(the idea is it will always be backward compatible and also forward
compatibly as good as it can)
- request2process mapping whereas a process is defined by a resource type
- seperation of "request" navigation from repository navigation
Thanks
MIchi
>
> -- Andreas
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
> 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.
BTW, if you consider these ideas valuable for 1.4, IMO it would be
nice if you could post a summary so that the community gets an
overview without examining the code. WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Andreas Hartmann <an...@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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Michael Wechner <mi...@wyona.com>.
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.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Andreas Hartmann <an...@apache.org>.
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.
>> 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.
>> 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.
Thanks for your reply,
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
not yet another out-of-tree prototype :'(
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Michael Wechner wrote:
> 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.
i'm sorry, but this code is not going to speak to me. how is anybody in
our small community supposed to read and understand all those alternate
trees?
i have both a life and a job, and while i'm strongly motivated to learn
the lenya trunk and contribute, i lack the resources and leisure time to
dig into yet another complete re-implementation. i hate uml as much as
anyone, but in situations like these i wish people would come up with
boxes and arrows for a change.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Michael Wechner <mi...@wyona.com>.
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?
> 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 ;-)
> 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.
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org