On Fri, Dec 8, 2017 at 12:43 PM, <bits...@gmail.com> wrote: > > In addition to that I think our viewpoints on test caching are different > because our use cases of Go are different. I come upon this feature not as > someone who deals with large berths of unchanging Go packages all the time > (Go and it's standard library, presumably like yourself), but relatively > small packages that interact with databases. In my use case I don't want my > tests cached on my primary project as my test bottleneck is not the Go code > that would be cached, but the database interaction that cannot be cached > (because of the lack of invalidation at this layer). I understand you'd like > me to try it, but if there's a provable theoretical problem with it, isn't > it practical to address it, and isn't switching the default a reasonable way > to address that?
How does your program interact with your database? Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
