On Sep 20, 2006, at 9:33 AM, Wolfgang Keller wrote: > For such cases, <duck> Modeling </duck> provides a mechanism that > "broadcasts" changes made by one "editing context" to all others upon > committing. Maybe they could share code with SQLAlchemy?
if someone wants to write an extension, most easily to sessioncontext, that just synchronizes data between open sessions, thats not a big deal. But it really is somewhat of a reinvention of the database itself. the Session only represents the set of objects youre working on *right now*. if i wrote a function that loaded a row from a database, and then i was going to operate on some of those values, would i want those values to magically change while i was in the middle of my operation ? > Personally, I agree with SGI that: > > "GUI tools should not mislead the user; they should display the > current state > of the system, even when changes to the system originate from > outside of the > tools themselves." > > (Citation from http://oss.sgi.com/projects/fam/). > > So imho the GUI of a database application should always reflect the > current > state of the data in the database. Without polling, of course. Not > like e.g. > this ยง$%&@! Windows "Explorer"... > I would not agree that SA is a GUI, and i wouldnt agree that a GUI should always reflect the current state of the database. if i open up a document and im editing the document, and i havent yet pressed "save", the GUI does not represent the current state of the database. > Unfortunately there seems to be no "standard" mechanism to register > a client > with the database itself for notification of any updates to > records. Even the > PostgreSQL-specific "listen" and "notify" commands require polling to > retrieve the notification events as far as I understand from the > documentation. because nobody uses stuff like that. really, its not the end of the world to have to deal with normal data synchronization issues. > > I wonder whether PL/Python support in PostgreSQL would allow to > implement > something like such an asynchronous notification system... > its a solution in search of a problem. ;) come up with the application first and show that this is something really necessary...the reason there arent too many tools for this sort of thing is because they are usually not needed ! ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
