PDA

View Full Version : 6.0 - question for Dan - regular 10 min DB commit



Triode
2005-02-11, 11:00
Dan,

I've been looking at the regular 10 min commit in DBIStore.pm, with a view to turning it off when the server is not active so that
the disks can spin down.
[Background being that my server disks have been spun up for 4 weeks now with 6.0 and have started to generate some smart
errors....]

Does DBIStore.pm include all the functions which touch the database? If so I assume it is fair to add a flag which is set by any
function updating the database and not calling commit. I can then check this flag in _commitDBTimer() to make the commit optional
and reset the flag?

Adrian

Dan Sully
2005-02-11, 11:31
* Triode shaped the electrons to say...

>I've been looking at the regular 10 min commit in DBIStore.pm, with a view
>to turning it off when the server is not active so that the disks can spin down.
>[Background being that my server disks have been spun up for 4 weeks now
>with 6.0 and have started to generate some smart errors....]
>
>Does DBIStore.pm include all the functions which touch the database? If so
>I assume it is fair to add a flag which is set by any function updating the
>database and not calling commit. I can then check this flag in
>_commitDBTimer() to make the commit optional and reset the flag?

Yes, we had discussed having a $isDirty flag, but no one has gotten around to
doing it. DBIStore.pm is the only place where the DB commits happen. Other
modules call ->update(), which doesn't write to the DB, but is probably where
(at least one) the dirty/not dirty should be detected.

update() should probably be subclassed in DataModel.pm (which is a subclass
of Class::DBI) to capture that.

-D
--
<noah> I'm partial to lipstick lesbians, I guess, but I suppose that's
a little like saying you're partial to blue when you're blind.

kdf
2005-02-11, 11:50
Quoting Dan Sully <dan (AT) slimdevices (DOT) com>:

> * Triode shaped the electrons to say...
>
> >I've been looking at the regular 10 min commit in DBIStore.pm, with a view
> >to turning it off when the server is not active so that the disks can spin
> down.
> >[Background being that my server disks have been spun up for 4 weeks now
> >with 6.0 and have started to generate some smart errors....]
> >
> >Does DBIStore.pm include all the functions which touch the database? If so
> >I assume it is fair to add a flag which is set by any function updating the
> >database and not calling commit. I can then check this flag in
> >_commitDBTimer() to make the commit optional and reset the flag?
>
> Yes, we had discussed having a $isDirty flag, but no one has gotten around to
> doing it. DBIStore.pm is the only place where the DB commits happen. Other
> modules call ->update(), which doesn't write to the DB, but is probably where
> (at least one) the dirty/not dirty should be detected.
>
> update() should probably be subclassed in DataModel.pm (which is a subclass
> of Class::DBI) to capture that.

as part of the import plugins, I've had to set the cover and thumb properties
from Track::coverArt. This causes some warning outputs regarding dropped a
track:
Slim::DataStores::DBI::Track Slim::DataStores::DBI::Track=HASH(0x76b8a64)
destroyed without saving changes to thumb at
D:/slim/imports/Slim/DataStores/DBI/DBIStore.pm line 890

would ->update() be the way to solve this? or am I doing this completely wrong?

-kdf

Dan Sully
2005-02-11, 11:55
* kdf shaped the electrons to say...

>would ->update() be the way to solve this? or am I doing this completely wrong?

->update should work.

-D
--
<noah> I used to be indecisive, but now I'm not sure.

Triode
2005-02-11, 14:33
Dan,

As a concept - do you mean something like the attached? This seams to allow the commits to be suppressed and potentially allows the
periodic commits to be run more frequently (once a min?)

I've put the $dirtyCount var in DataModel.pm because this seamed easiest, but this may need to be moved if other modules need to
update it.

Adrian
----- Original Message -----
From: "Dan Sully" <dan (AT) slimdevices (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Friday, February 11, 2005 6:31 PM
Subject: [Developers] Re: 6.0 - question for Dan - regular 10 min DB commit


>* Triode shaped the electrons to say...
>
>>I've been looking at the regular 10 min commit in DBIStore.pm, with a view to turning it off when the server is not active so that
>>the disks can spin down.
>>[Background being that my server disks have been spun up for 4 weeks now with 6.0 and have started to generate some smart
>>errors....]
>>
>>Does DBIStore.pm include all the functions which touch the database? If so I assume it is fair to add a flag which is set by any
>>function updating the database and not calling commit. I can then check this flag in _commitDBTimer() to make the commit optional
>>and reset the flag?
>
> Yes, we had discussed having a $isDirty flag, but no one has gotten around to
> doing it. DBIStore.pm is the only place where the DB commits happen. Other
> modules call ->update(), which doesn't write to the DB, but is probably where
> (at least one) the dirty/not dirty should be detected.
>
> update() should probably be subclassed in DataModel.pm (which is a subclass
> of Class::DBI) to capture that.
>
> -D
> --
> <noah> I'm partial to lipstick lesbians, I guess, but I suppose that's
> a little like saying you're partial to blue when you're blind.
>

Dan Sully
2005-02-11, 21:48
* Triode shaped the electrons to say...

>As a concept - do you mean something like the attached? This seams to
>allow the commits to be suppressed and potentially allows the periodic
>commits to be run more frequently (once a min?)

Looks good to me.

>I've put the $dirtyCount var in DataModel.pm because this seamed easiest,
>but this may need to be moved if other modules need to update it.

That's the right place for it. Everyone inherits from DataModel.

I'm going to commit this.

-D
--
Minds are like parachutes... they work best when open.