The Wayback Machine - https://web.archive.org/web/20210202225506/https://github.com/Nozbe/WatermelonDB/issues/186
Skip to content

/ WatermelonDB

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

Jump to bottom

Reduce memory usage in destroy process #186

Closed
ieschalier opened this issue Dec 17, 2018 · 6 comments
Closed

Reduce memory usage in destroy process #186

ieschalier opened this issue Dec 17, 2018 · 6 comments
Labels
wontfix

Comments

@ieschalier
Copy link
Contributor

@ieschalier ieschalier commented Dec 17, 2018

Description

With example it must be more understandable.

export default class List extends Model {
  static table = 'lists'

  static associations = {
    items: { type: 'has_many', foreignKey: 'list_id' },
  }

  @children('items')
  items

  destroyPermanently = async () => {
    await this.items.destroyAllPermanently()
    await super.destroyPermanently()
  }
}

In case of list with a lot of items, destroy List cause a peak of memory usage.

It must be a real problem in mobile because we have a limit of memory usage, after this limit app is killed by OS.

Proposal

Actually destroyAllPermanently seems to fetch all items one by one and delete then one by one. I think this is done for simplify manage of watermelon cache.

Do you think it’s possible to delete with a single query to avoid this peak of memory ?
@radex
Copy link
Member

@radex radex commented Dec 17, 2018

Do you think it’s possible to delete with a single query to avoid this peak of memory ?

It's possible, but not trivial. It's one of the TODO steps before 1.0. The problem is finding all dependencies (say, delete a project with all its tasks with all their comments), and then updating the JS state (removing all deleted items from local cache, notifying observers).

If you want to tackle this, or at least part of it, let me know — I'll give you pointers.

For quick workarounds, you could try chunking (fetch list.items, and then delete portions of the list in chunks), or you could try issuing a raw SQL query (#103)
@ieschalier
Copy link
Contributor Author

@ieschalier ieschalier commented Dec 17, 2018

Ok, we try with a raw SQL query and it's seems to work very well. Thanks for the tricks 🙂

I don’t have time in next 2 weeks but maybe after
@radex
Copy link
Member

@radex radex commented Feb 26, 2019

@ieschalier hey, what's the status of the issue for you?
@ieschalier
Copy link
Contributor Author

@ieschalier ieschalier commented Feb 27, 2019

Hey @radex, currently nobody in my team have time to work on this issue.

Usage of raw query do the job, but it's not the more pretty solution.
@radex
Copy link
Member

@radex radex commented Feb 27, 2019

Understood — thanks for the update!
@stale
Copy link

@stale stale bot commented May 28, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@stale stale bot added the wontfix label May 28, 2019
@radex radex closed this May 29, 2019
@radex radex mentioned this issue Jun 20, 2019
Open
2 of 5 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix
2 participants
@radex @ieschalier