Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Remove after_rollback from LogEntry #564

Closed
wants to merge 2 commits into from

Conversation

jhawthorn
Copy link
Contributor

WIP because I'm not yet 100% certain that removing that has no effect, need to test a bit more.

after_rollback has all kinds of problems. When it's run as part of our specs, the filter happens after our spec run (each spec is run inside a transaction), meaning that extra useless blank log entries end up in our database. Gross!

In core's test suite:

config.after(:suite){ p Spree::LogEntry.count } # => 149

I don't think we ever want this, if we were rolling back a log entry, we would also be rolling back a state change on a payment, which is bad.

This is similar to bc19fcb

@forkata
Copy link
Contributor

forkata commented Dec 4, 2015

❤️ 👍 This has plagued us for a long time. Thank you for taking the time to investigate and clean this mess up.

@cbrunsdon
Copy link
Contributor

That this breaks no specs terrifies me.

@jhawthorn should we try and get this in really early into 1.3 as well?

Also, we should write a spec that actually does something for this. As in: given we have a payment that fails, a log entry of it still exists. We should probably do that before we merge.

@jhawthorn jhawthorn added this to the 1.3.0 milestone Jan 12, 2016
@jhawthorn
Copy link
Contributor Author

Tagged for 1.3. We should make sure there is a spec covering payment failures.

jhawthorn and others added 2 commits January 21, 2016 09:57
This is trying to assign the payment's source to source. Not only is
that the wrong thing to do (a payment is the source of a log_entry), but
since it's being built through the payment.log_entries association, it
will have no effect.

Sometimes two wrongs do make a right!
@jhawthorn jhawthorn removed this from the 1.3.0 milestone Apr 13, 2016
@jhawthorn jhawthorn added the WIP label Apr 13, 2016
@tvdeyen
Copy link
Member

tvdeyen commented Jun 13, 2017

Closing as stale. Please reopen if this is still something we want to tackle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants