On Sep 18, 2004, at 11:05 AM, Toni Alatalo wrote:

> i suppose that should read self.company_name = company_name .
Thanks.  This will be corrected in the next Dulcinea release.

>
> One question: those Dulcinea classes don't seem to be persistent
> automatically, even though they inherit from DulcineaPersistent and
> hence
> the Durus persistence mechanisms, in the sense that changes to the
> classes
> are not immediately committed to the database. How do you / how should
> I
> deal with that?

Do you really mean changes to the *classes*?  The persistence mechanism
(of Durus) maintains persistent instances, so class attribute changes
don't
"stick".

>
> What I'm doing currently is that i have an abstract Resource
> superclass,
> which my persistent classes inherit (implement), with an update()
> method
> that further calls the server instance so that it commits to the db. So
> what works is to multiple inherit my own User class from that Resource
> and
> dulcinea.contact.ContactDatabase (or DulcineaUserDatabase), and extend
> the
> add_user method to call that update method after changes, like this:
>
> (in a specialized user module for an app)
> class UserDatabase(Resource, ContactDatabase):
>     """ has .admin and .users """
>     user_class = User
>
> (...)
>
>     def add_user(self, user):
>         """extends DulcineaUserDatabase to have the data persistent in
>         this system"""
>         ContactDatabase.add_user(self, user)
>         self.update()
>
> So that works. If I add users and kill the server immediately after
> that,
> they are there after restart. But now if I want the same for the whole
> Dulcinea user management machinery, so that e.g. the plethora of
> methods
> of the Contact class (that may well be useful for me), like set_prefix,
> set_first_name, record_login, record_logout etc. work similarily, i.e.
> that the changes are immediately committed to the db after they have
> been
> done, do I need to override all those methods or is there some better
> way?
> Intervening with __setattr__ might be one, but probably not be good -
> or?

I would not recommend intervening with __setattr__.
Overriding the methods seems like the clearest way to get the
behavior you are describing.  I think you should consider changing
to the strategy of calling commit after a consistent set of changes is
completed.

>
> Hm, perhaps this would better fit the Durus-users list -- subscribed
> there
> so will get the potential answers via that too. I remember there was
> some
> mention of the _changed attribute or something, will study that more.

I think you are thinking of the "_p_changed" property of Persistent
instances.
The line "self._p_changed = 1" in a method, after changes to
non-Persistent
container attributes, might be what you are looking for.  You might
want to look at
the source for durus.persistent_dict.PersistentDict for an example of
this.