[Question] More details on offline first?

[gen1lee]

So is it database first?

Does user need to wait until data is written to db before components can render it?

If yes, what will happen if there is not enough space on disk?

[SaltedBlowfish]

So is it database first?

What does this mean?

Does user need to wait until data is written to db before components can render it?

If you are trying to use data you have not written to the database, no, it won't be there. How would Watermelon see data you have not put into the database?

If yes, what will happen if there is not enough space on disk?

Highly unlikely. Very highly unlikely, but the platform will notify the user that they're running low on disk space in general.

[gen1lee]

@SaltedBlowfish

It can cache data in memory and provide to components, before writing to db.

And pls lets post here if you fully understand the question and watermelon architecture.

[KrisLau]

It's a client side DB and you can always use tables before any data is inserted and it will be updated when data is inserted if you use the observables functions. For more in depth stuff please read through the docs like https://nozbe.github.io/WatermelonDB/ch04-00-deeper.html

[gen1lee]

@KrisLau you don't understand the question.

[KrisLau]

@gen1lee Then elaborate lol cause me and @SaltedBlowfish both don't understand what exactly you're asking.

[SaltedBlowfish]

@gen1lee I think he did understand the question, but you're not asking the right question. Your original questions are very difficult to find reasoning for to begin with.

So is it database first?

It's a database. Not first, not last, not in any order. It's a database. An offline database. Not connected to the internet.

Does user need to wait until data is written to db before components can render it?

Yes. Data comes from database but can be observed with RXJS. The database must have the data in order for the components using the data to update.

Watermelon will not memory-write and emulate a database write, but you can use observable functions to watch for the database changes.

If yes, what will happen if there is not enough space on disk?

Not sure but like I said, the phone will let you know if you're running low on disk space. To my knowledge, no one has tested this so please write a test and let us know how it goes.

[gen1lee]

@SaltedBlowfish ok lets ask differently:

1. does it manage some in-memory cache?
2. when do observers receive changes - before actual write to database or after? First is much faster.
3. Imagine if I reply to someone [in chat app], but there is not enough space on disk - what will happen? reply won't appear or it just won't be persisted? Second is better.
4. This DB is a good candidate to be used for chats, but chats are done with optimistic responses - when memory cache is updated two times - before and after response received. How we can achieve that here? Does it require additional layer?

[Albert-Gao]

@gen1lee

does it manage some in-memory cache?

No, why do you need a memcache for writing, which is a huge problem.

when do observers receive changes - before actual write to database or after? First is much faster.

Of course after, if before, that is optimistic update, and you do know the problems it introduces aye? And with a local db, why do you want to use the fragile optimistic update to shoot yourself in the foot? And what kind of performance will you gain? Have you benchmarked it? Or just imagining in your head?

Imagine if I reply to someone [in chat app], but there is not enough space on disk - what will happen? reply won't appear or it just won't be persisted? Second is better.

Then an error will thrown and the message won't be persisted, how come the db can persist the data if there is no space.....

This DB is a good candidate to be used for chats, but chats are done with optimistic responses - when memory cache is updated two times - before and after response received. How we can achieve that here? Does it require additional layer?

It sounds like you are describing optimistic updates which is completely irrelevant to watermelon db since its local db nature, go use a client side query library with a cache.

[gen1lee]

1. It actually does, but only for getting entities by id. Which is definitely not enough for making a fast app.
2. This is very bad for performance either.
3. This just makes it useless if app stops working without disk space.
4. It definitely doesn't have optimistic updates without in-memory cache, so yeah, minus here as well.

Actually I've investigated it myself and have a conclusion that I can't imagine any app that will work better using this db instead of some kind of redux-persist approach or custom faster version of it with sqilte.

[SaltedBlowfish]

@gen1lee

I'm sorry you think that WatermelonDB has fatal performance flaws and is unsuited to your application.

Looking forward to your PR to fix these issues.

[Albert-Gao]

@gen1lee

I went through the research and found there is actually no good alternative for watermelon db which can provide the same performance and features. definitely has pros and cons, but not the one you were mentioned....

Considering the fact that you are constantly thinking about non-existing problems or misunderstood different layers in architecture even for a client-side app...... You might want to learn some basic knowledge then deving....

I think either learning some fundamental engineering stuff or just try building your own version of watermelon db is the best way for you to learn.

[gen1lee]

@Albert-Gao

before giving such advices you better learn how to build high performance client apps first, or just study some client app architecture basics at least.

And I would never write something like watermelonDB - don't wanna waste my time.

[radex]

@gen1lee then stop wasting everyone else's time

[KrisLau]

Btw @radex could you take a look at #1249. An expo maintainer created this pull request which has been tested by quite a few people and it seems to work well. Without the patch, any project with expo crashes.