15 Matching Annotations
  1. Apr 2022
    1. These callbacks are smart enough to run after the final (outer) transaction* is committed. * Usually, there is one real transaction and nested transactions are implemented through savepoints (see, for example, PostgreSQL).

      important qualification: the outer transaction, the (only) real transaction

    1. These callbacks are focused on the transactions, instead of specific model actions.

      At least I think this is talking about this as limitation/problem.

      The limitation/problem being that it's not good/useful for performing after-transaction code only for specific actions.

      But the next sentence "This is beneficial..." seems contradictory, so I'm a bit confused/unclear of what the intention is...

      Looking at this project more, it doesn't appear to solve the "after-transaction code only for specific actions" problem like I initially thought it did (and like https://github.com/grosser/ar_after_transaction does), so I believe I was mistaken. Still not sure what is meant by "instead of specific model actions". Are they claiming that "before_commit_on_create" for example is a "specific model action"? (hardly!) That seems almost identical to the (not specific enough) callbacks provided natively by Rails. Oh yeah, I guess they do point out that Rails 3 adds this functionality, so this gem is only needed for Rails 2.

    1. In this case, the worker process query the newly-created notification before main process commits the transaction, it will raise NotFoundError, because transaction in worker process can't read uncommitted notification from transaction in main process.
  2. Feb 2021
  3. Oct 2020
  4. Aug 2020
    1. Allows batch updates by silencing notifications while the fn is running. Example: form.batch(() => { form.change('firstName', 'Erik') // listeners not notified form.change('lastName', 'Rasmussen') // listeners not notified }) // NOW all listeners notified
  5. Jun 2020
    1. transaction calls can be nested. By default, this makes all database statements in the nested transaction block become part of the parent transaction. For example, the following behavior may be surprising: User.transaction do User.create(username: 'Kotori') User.transaction do User.create(username: 'Nemu') raise ActiveRecord::Rollback end end creates both “Kotori” and “Nemu”. Reason is the ActiveRecord::Rollback exception in the nested block does not issue a ROLLBACK. Since these exceptions are captured in transaction blocks, the parent block does not see it and the real transaction is committed.

      How is this okay??

      When would it ever be the desired/intended behavior for a raise ActiveRecord::Rollback to have absolutely no effect? What good is the transaction then??

      What happened to the principle of least surprise?

      Is there any reason we shouldn't just always use requires_new: true?

      If, like they say, the inner transaction "become[s] part of the parent transaction", then if anything, it should roll back the parent transaction too — not roll back nothing.

    2. One workaround is to begin a transaction on each class whose models you alter:
  6. Apr 2020
  7. Sep 2019
    1. Expert Smart Contract Development Guide for 2019

      What is a smart contract?

      For those of you who don’t know, a smart contract is a self-executing contract that digitally facilitates, verifies and enforces the agreed terms between two or more parties.

  8. Jul 2019
    1. It seems to me that in considering the purpose of a subset of the entire series of transactions, Justice Paris had in mind the correct test. As this Court said in MacKay v. Canada, 2008 FCA 105 (CanLII) at paragraph 25: The existence of a bona fide non-tax purpose for a series of transactions does not exclude the possibility that the primary purpose of one or more transactions within the series is to obtain a tax benefit.

      Existence of a bona fide non-tax purpose for a series of transactions does not exclude possibility that the primary purpose of one of the transactions in the series is to obtain a tax benefit.

  9. Jun 2016
    1. As Katzen (1980, p. 191) notes in heranalysis of early volumes of thePhilosophical Transac-tions:. . . no attempt is made to give prominence to the author ofthe article . . . there is generally no reference at all to theauthor in the heading that signals a new communication. Ifthe author is referred to in the title, it is likely to be in anoblique form . . . we are at the threshold between anony-mous and eponymous authorship

      Study of authorship in Philosophical transactions