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

A way to disable recalculation temporarily #148

Open
Alex-Sichkar opened this issue Apr 11, 2024 · 6 comments
Open

A way to disable recalculation temporarily #148

Alex-Sichkar opened this issue Apr 11, 2024 · 6 comments

Comments

@Alex-Sichkar
Copy link

For some cases, there is a need to disable recalculation during complex operations (e.g., merging some objects, etc.). I know I can use bulk ORM operations to achieve this, but I think an explicit way is much better, maybe some context manager?

Once again, thank you for the fantastic project!

@jerch
Copy link
Collaborator

jerch commented Apr 11, 2024

Interesting that you bring this up, in fact I had this mind for some time already. The question is - would it be enough to disable all CF actions in that context and tell ppl, that they have to resync things manually after that? This opens the door for "oops, forgot about this or that dependency" out-of-sync errors in the datasets. But sure, if thats good enough, than a simple context thingy like this should do:

with no_computed():
    # do your de-sync processing here
    ...
# here should re-sync manually

Well I am not sure, if manually resolving the de-sync issues is too much of a burden for any dev, it really depends on the changes done in the de-sync block. And tracking that automatically w'o actually doing the computation is almost impossible due to the depth-first recursion and unchanged value tree-cutoff of the resolver.

So overall I am not against a context to switch everything CF-related off, but I am unsure about the practical impact for peeps w'o automatic re-sync. Maybe you have a better idea than just warn peeps to use that very carefully?

@Alex-Sichkar
Copy link
Author

Maybe just synchronize everything upon exiting the context manager block (by default)?

@jerch
Copy link
Collaborator

jerch commented Apr 11, 2024

Maybe just synchronize everything upon exiting the context manager block (by default)?

Imho thats not a good idea - for any reasonably sized database with tricky CF setup this might cause a really nasty runtime impact. 😱

Can you share some details, what you'd need this for? Maybe its easier to approach this with a realword example...

@Alex-Sichkar
Copy link
Author

I mean re-sync not everything, but stuff changed in the context manager scope.

Realword example:

def merge_orders(orders):
    result = orders[0]
    others = orders[1:]
    for o in others:
        for item in o.items.all():
            try:
                result_item = result.items.get(
                    product_id=item.product.id,
                )
            except OrderItem.DoesNotExist:
                item.order = result
                item.save()
            else:
                result_item.quantity += item.quantity
                result_item.save()
                item.delete()

        o.delete()

    result.save()  # I only need to synchronize here
    return result

@jerch
Copy link
Collaborator

jerch commented Apr 11, 2024

I mean re-sync not everything, but stuff changed in the context manager scope.

Well thats what I mean with "tracking changes". That's not easy doable in an automated fashion. But for your real-world case maybe giving hints to the context, what to sync back, would be possible.

@Alex-Sichkar
Copy link
Author

Alex-Sichkar commented Apr 11, 2024

That's not easy doable in an automated fashion

I understand...

So perhaps just provide a way to disable it? Users don't have to use it anyway; this would be a kind of "advanced cases" similar to using bulk operations (after using it, users have to sync stuff manually).

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

No branches or pull requests

2 participants