You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have prepared enough utilities to detach the TableReacerExecutor's context from the session context now! Let's finish the last step before starting to develop a new cursor fetch!
It's not that convenient to copy these contexts again (especially for WarnHandler, which is shared in almost every context). To solve this complicated construction issue, a DI framework is usually used. However, I think it over complicates the logic. A better solution (IMO) is to just leave these fields. Re-think that these fields cannot be used across multiple statements because two reasons:
They are shared and can be modified by the next statement, so it's not safe to keep using it.
The memory is cleared before executing the next statement, so keeping a reference to it is not safe.
For the first situation, we have to copy the internal value. For the second situation, we can just leave it! And allocate/create new one for each statement, so the previous one doesn't need to be cleared (and the GC will help us to free these memory later). Using this strategy, it'll be much simpler to refactor.
The text was updated successfully, but these errors were encountered:
Enhancement
We have prepared enough utilities to detach the
TableReacerExecutor
's context from the session context now! Let's finish the last step before starting to develop a new cursor fetch!It's not that convenient to copy these contexts again (especially for
WarnHandler
, which is shared in almost every context). To solve this complicated construction issue, a DI framework is usually used. However, I think it over complicates the logic. A better solution (IMO) is to just leave these fields. Re-think that these fields cannot be used across multiple statements because two reasons:For the first situation, we have to copy the internal value. For the second situation, we can just leave it! And allocate/create new one for each statement, so the previous one doesn't need to be cleared (and the GC will help us to free these memory later). Using this strategy, it'll be much simpler to refactor.
The text was updated successfully, but these errors were encountered: