On 11/27/2012 01:40 PM, Simon Slavin wrote:
On 27 Nov 2012, at 3:58am, Yongil Jang <[email protected]> wrote:
What I'd done to solve this problem is reading change counter in db file
header.
Or watch the modification date of the database file.
Right, except what I need is to know exactly which row was
added, removed or updated (and polling is of course completely
out of the question).
Actually, to give some context, currently I have SQLite
underneath an IPC already (Evolution Data Server contacts
database).
When writes are performed, they go over the IPC and are written
by the addressbook server to the underlying SQLite.
Likewise, this same IPC notifies connected clients whenever
a contact is added/removed/changed (in add/change notifications,
all contact data is propagated over the IPC).
We've proven that fetching the data directly, without going
through the IPC, improves performance dramatically
(i.e. the serialization of contact data and pushing that
data over the IPC is completely avoided if the SQLite
is accessed directly at least for read operations).
Now what I'd like to do additionally is notify clients
of changes without the IPC, relying only on SQLite's
presumably lightweight IPC change notifications
(notifications which, I'm now discovering don't
exist...)
If SQLite could at least notify us which row was
added/removed/changed, then we could potentially
propagate that change to the client directly
at least without serializing/deserializing the
contact data and pushing the whole thing through
the IPC.
At any rate, I figure I'll need to go with some
hybrid solution where clients can receive minimal
data in notifications and then fetch the data directly.
Cheers,
-Tristan
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
