Re: [gnome-db] GdaDataModel signals

On 6/12/07, Diego Zuccato <diego otello alma unibo it> wrote:
Vivien Malerba ha scritto:
>> Is GdaDataModel a rowset which detects changes into database? Or is it
>> like a CachedRowSet in Java [an offline rowset with no notifications of
>> changes in db data]?
> The data model retuned when executing a query does not detect changes
> made in the database (in fact I don't know if any DBMS offers an API
> to do so, if you have any example, please tell me). I think it's like
> a CachedRowSet in Java.

I did it in Postges using NOTIFY and triggers. But it's quite hard to do
it in a general way. And it's quite limited, too, since the NOTIFY
doesn't allow additional data to be passed :( It's too like a *NIX
kill() call...

The problem here is that this (partial) solution is very tied to
PostgreSQL and requires the setup of some triggers, which means
modifying the accessed DB, which I've managed to avoid up to now (this
guarantees that none of libgda's features does any modification to a
DB withot the user knowing it).

> Now there is the GdaDataModelQuery object which lets you run a SELECT
> statement and any modification you make to the data model is
> translated into the correcponding UPDATE, INSERT or DELETE queries, so
> the database is modified in the same way as the data model is
> modified.

But it only reflects LOCAL changes. If another client is updating the
db, then THOSE changes are "lost" for the local client.

Yes, that's right.

>> what about if I insert/update a row from an external sqlite console?
> Then you'll see the changes you made if you execute the query again.

Obviously he could setup a NOTIFY trigger in PG to rescan the table
(this is good only for SMALL tables!). The method I used needed a
trigger to insert the modified ROWID and a timestamp in an auxiliary
table, where another trigger issued the NOTIFY to the clients listening.
After a "long-enough" timeout older entries were deleted.
Depending on his architecture, a multi-daemon or some other sort of IPC
might be better.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]