13 Matching Annotations
  1. Aug 2023
    1. I think the problem with after_destroy is that it is triggered before the database commits. This means the change may not yet be seen by other processes querying the database; it also means the change could be rolled back, and never actually commited. Since shrine deletes the attachment in this hook, that would mean it might delete the attachment prematurely, or even delete the attachment when the record never ends up destroyed in the database at all (in case of rollback), which would be bad. For shrine's logic to work as expected here, it really does need to be triggered only after the DB commit in which the model destroy is committed.
  2. Feb 2023
    1. If you already have an instance of your model, you can start a transaction and acquire the lock in one go using the following code: book = Book.first book.with_lock do # This block is called within a transaction, # book is already locked. book.increment!(:views) end
  3. 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.
  4. Feb 2021
  5. Oct 2020
  6. 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
  7. 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:
  8. Apr 2020