14 Matching Annotations
  1. Jun 2020
    1. However, a ActiveRecord::Rollback within the nested transaction will be caught by the block of the nested transaction, but will be ignored by the outer transaction, and not cause a roll back! To avoid this unexpected behaviour, you have to explicitly tell rails for each transaction to indeed use proper nesting: CopyActiveRecord::Base.transaction(joinable: false, requires_new: true) do # inner code end This is a safer default for working with custom transactions.
    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. May 2020
    1. Chances are that you think that you can compile a Ruby binary on a certain OS, and that users using that same OS can use your Ruby binary. Not quite. Not even when they run the same OS version as you do.
    1. If we find that GitLab doesn't work as people expect, the documentation should be updated so this is no longer a surprise. This applies whether we classify it as a feature request or a bug.
    1. Unexpected features “Unexpected” features are those that are unrelated to the add-on’s primary function, and are not likely from the add-on name or description to be expected by a user installing that add-on. Should an add-on include any unexpected feature that falls into one of the following categories: Potentially compromises user privacy or security (like sending data to third parties) Changes default settings like the new tab page, homepage or search engine Makes unexpected changes to the browser or web content Includes features or functionality not related to the add-on’s core function(s) Then the “unexpected” feature(s) must adhere to all of the following requirements: The add-on description must clearly state what changes the add-on makes. All changes must be “opt-in”, meaning the user has to take non-default action to enact the change. Changes that prompt the user via the permissions system don’t require an additional opt-in. The opt-in interface must clearly state the name of the add-on requesting the change.
  3. Apr 2020
  4. Mar 2020
    1. To be just a bit polemic, your first instinct was not to do that. And you probably wouldn't think of that in your unit tests either (the holy grail of dynamic langs). So someday it would blow up at runtime, and THEN you'd add that safeguard.
    2. As many would guess: ... catch StandardError => e raise $! ... raises the same error referenced by $!, the same as simply calling: ... catch StandardError => e raise ... but probably not for the reasons one might think. In this case, the call to raise is NOT just raising the object in $!...it raises the result of $!.exception(nil), which in this case happens to be $!.
    1. Legitimate Interest may be used for marketing purposes as long as it has a minimal impact on a data subject’s privacy and it is likely the data subject will not object to the processing or be surprised by it.
  5. Feb 2020
    1. The .ignore file , from what I can tell, needs to exist in the directory you're targeting for it to be recognized, not the current directory. If you're searching in .src, the file would need to be there for it to work.
  6. Mar 2019
    1. "sing aloud," and perhaps because shc diclnot, she crossed the sound barrier long before other women learrrt.rlto fly. Writing for pleasure, she wrote what she pleased

      I like how this passage suggests that because Dickinson kept her work private, she was able to progress further than her female contemporaries who, as I read it, were shackled by sociatal expectations of what art is, or how a woman should be writing and therfore could not contend with Dickinson's unfettered imagination--the results of which were largely unrecognized until after her death.

    2. trauma

      I love how "disapointment in love" is described as traumatic--it's also interesting how trauma sometimes engenders art--and how lonlieness, heartbreak, and dissatisfaction inspire many to create and can be labled as "traumatic" events or feelings.