On Sep 24, 2013, at 10:42 AM, Aleksandr Kuznetsov <aku.ru...@gmail.com> wrote:
> Hi! > > I have ModelA model (declarative style) for persistent table. I have to > periodically update that table with some external data (replace existing data > with new). silly question, is there a reason standard replication techniques provided by the database can't be used here? they might be a little more heavy-handed to set up than some in-app trick but it'll work more solidly. > It must be performed with minimal locking and there must not be mixed old > data and new data. I see the follwing way to implement it: create some > temporary table like ModelA table, say it will be ModelATmp; fill ModelATmp > with new external data; Replace ModelA table with new created table (SQL: > RENAME TABLE a_table TO a_table_prev; RENAME TABLE a_tmp_table TO a_table; > DROP TABLE a_table_prev;). > > I'm wondering what is a right way to implement such scenario? I want to > create some table rotator class, pass to it ModelA, get from it ModelATmp, > fill it and rotate tables with that rotator. Is it possible? How should I do > it? as always, the main issue is concurrency. can you guarantee that exactly one connection at a time will be performing this operation and that during so, no other connections will have any read or write locks of any kind on this table? otherwise it's not going to work. to implement the scenario, assuming you've figured out how to make sure a connection has exclusive access, you've already spelled it out - just execute the SQL you've described on the connection. as far as "build a class" or whatnot that sort of depends on app architecture, I'd not bother creating a class if there's just one function and no overarching pattern of class construction (see "Stop Writing Classes!" for the general idea: http://pyvideo.org/video/880/ )
signature.asc
Description: Message signed with OpenPGP using GPGMail
