[ChangeLog] Destroy() method semantic

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

I'm looking at the MemoryChangeLogStore, and the destroy() method
implementation do a full save on disk :

public void destroy() throws Exception
{
    saveRevision();
    saveTags();
    saveChangeLog();
}

Is there any reason to do that ? Shouldn't we remove everything
instead of saving data ?

It's not necessarily important for the memory CL, but for a disk CL,
we have to decide what is the exact semantic of this method.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [ChangeLog] Destroy() method semantic

[Alex Karasulu <ak...@gmail.com>]

These are standard service management functions. Sometimes it's
start()/stop(), open()/close(), create()/destroy().  Which ever works so
long as we're consistent.

On Thu, Jan 29, 2009 at 9:27 AM, Emmanuel Lécharny <el...@iktek.com>wrote:

> Alex Karasulu wrote:
>
>> The method name is fine. It is intended to denote cleanup of resources
>> needed for the CL.
>>
>> This in memory CL was a very very simple proof of concept implementation.
>>  I
>> added the code to backup the content of the CL to a file which get's read
>> on
>> startup to persist changes instead of loosing them.  This mimics a real
>> persistent CL for testing purposes.  If you change this then several tests
>> will begin to fail.  The point is any CL should persist change events,
>> even
>> if this implementation is just a toy.
>>
>>
> It's a bit surprising that everything is stored on disk when you do a
> destroy()... Last time my computer was destroyed, I wish the data were
> stored on disk at the same time ;)
>
> More seriously, I understand the logic, but using close() instead of
> destroy() would have been better.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

Re: [ChangeLog] Destroy() method semantic

[Alex Karasulu <ak...@gmail.com>]

The method name is fine. It is intended to denote cleanup of resources
needed for the CL.

This in memory CL was a very very simple proof of concept implementation.  I
added the code to backup the content of the CL to a file which get's read on
startup to persist changes instead of loosing them.  This mimics a real
persistent CL for testing purposes.  If you change this then several tests
will begin to fail.  The point is any CL should persist change events, even
if this implementation is just a toy.

Alex

On Wed, Jan 28, 2009 at 1:14 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

> On Wed, Jan 28, 2009 at 7:05 PM, Kiran Ayyagari <ay...@gmail.com>
> wrote:
> >
> > AFAIU, the destroy in CL is intended for flushing the changes and closing
> > the open resources
> > rather than for removing. I have implemented a custom CL's destroy() in
> the
> > same way.
> >
> > May be the method name is misleading.
>
> Probably :)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Re: [ChangeLog] Destroy() method semantic

[Emmanuel Lecharny <el...@gmail.com>]

On Wed, Jan 28, 2009 at 7:05 PM, Kiran Ayyagari <ay...@gmail.com> wrote:
>
> AFAIU, the destroy in CL is intended for flushing the changes and closing
> the open resources
> rather than for removing. I have implemented a custom CL's destroy() in the
> same way.
>
> May be the method name is misleading.

Probably :)

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [ChangeLog] Destroy() method semantic

[Kiran Ayyagari <ay...@gmail.com>]

AFAIU, the destroy in CL is intended for flushing the changes and closing the open resources
rather than for removing. I have implemented a custom CL's destroy() in the same way.

May be the method name is misleading.

Kiran Ayyagari

Emmanuel Lecharny wrote:
> Hi,
> 
> I'm looking at the MemoryChangeLogStore, and the destroy() method
> implementation do a full save on disk :
> 
> public void destroy() throws Exception
> {
>     saveRevision();
>     saveTags();
>     saveChangeLog();
> }
> 
> Is there any reason to do that ? Shouldn't we remove everything
> instead of saving data ?
> 
> It's not necessarily important for the memory CL, but for a disk CL,
> we have to decide what is the exact semantic of this method.
> 
>