Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Still, I don't think that quite solves the problem if you assert a fact and your query fails, you probably want to retract that fact.

    This feels to me like you want an 'alternative futures' model of time: that is, when you backtrack, you not only go back to a previous 'time' but also arrange things so that when you go 'forward' again you are moving forward on a different timeline that diverges from the first at the point the backtrack went back to. If you change something and don't backtrack, subsequent c

  • have been wrestling with these sort of concurrency issues for decades now (and of course you can view the DB as a set of assertions). With something like mvcc you're not even dealing with a single timeline any more.

    • http://www.postgresql.org/docs/8.3/static/mvcc.html
    • http://wiki.postgresql.org/wiki/MVCC
    • http://www.postgresql.org/docs/8.3/static/transaction-iso.html

    There's been a recent discussion on the pgsql-hackers list wrt some issues of implementing true serializable transactions that might feed in to

  • I was going to post some useful references coz I spent a large chunk of time with my undergraduate project implementing a temporal reasoning system based around a constraint propagation mechanism, intending it to form the backbone of a multi-agent planner.

    Then I realised that was eighteen years ago and I cannot remember anything about the bugger - beyond the fact that it was annoyingly NP-complete and ran far too slowly to do anything useful.

    Sorry!