durusmail: quixote-users: dulcinea.contact: a bug, and making the data persistent
dulcinea.contact: a bug, and making the data persistent
2004-09-18
2004-09-18
dulcinea.contact: a bug, and making the data persistent
2004-09-19
dulcinea.contact: a bug, and making the data persistent
Toni Alatalo
2004-09-18
Greetings.

There seems to be a small bug in the Contact class of the dulcinea.contact
module (this is Dulcinea 0.3), in the set_company_name method, which is:

    def set_company_name(self, company_name):
        typecheck(company_name, str, allow_none=1)
        self.company_name

i suppose that should read self.company_name = company_name .

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?

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?

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.

~Toni


reply