On Thu, Feb 16, 2006 at 06:09:15PM -0800, w b wrote: > At the moment when I pull back the row. I package it up in to a > network byte order representation and send it on its merry way. The > recv's of course unpack the message and then refresh their local > information with the information sent, again in a SQLITE DB having > the same table structure as what it originated from. > > So I was thinking (Dangerous with out too much coffee!) if the DB > format is platform neutral is there a way to obtain a raw image of > that row from SQLITE rather than performing the sqlite3_column_XXX > for each field returned.
That might be an interesting or useful technique for other uses as well, say if you were trying to make clusters of SQLite engines act as one consistent database. Your "raw row" idea sounds at least superficially related to what the old Postgres-R project did for multi-master replication. In Postgres-R, basically each node would process the SQL for a transaction, then ship a much lower level representation of that transaction to the other nodes, using one of the academic group communicatins toolkits, either Spread or (I think) Ensemble. Since for many transactions applying this lower level representation was much more efficient than processing the original SQL, this gave some scalability. Bettina Kemme's paper from 2000, "Don't be lazy, be consistent: Postgres-R, a new way to implement Database Replication." describes it: http://openacs.org/forums/message-view?message_id=128917 http://www.informatik.uni-trier.de/~ley/db/conf/vldb/KemmeA00.html Postgres-R was research-ware based on an ancient 6.x version of PostgreSQL (from before MVCC!), and AFAIK no one ever drummed up enough interest and manpower to actually finish forward porting it to a more recent PostgreSQL version. But it seemed interesting. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
