"Uh-oh" error occurs when enabling "debug mode"— database works!

[Tycholiz]

Interestingly I have been able to locate the SQLite database that WatermelonDB is creating, and I can see that records are indeed being created when I execute methods from within the app. However, when I enable "debug mode" so that I can connect to a debugger (as I normally do), I get the notorious "Uh-oh" error:

WatermelonDB] Uh-oh. Database failed to load, we're in big trouble. This might happen if you didn't set up native code correctly (iOS, Android), or if you didn't recompile native app after WatermelonDB update. It might also mean that IndexedDB or SQLite refused to open.

Invariant Violation: Calling synchronous methods on native modules is not supported in Chrome. Consider providing alternative methods to expose this method in debug mode, e.g. by exposing constants ahead-of-time.

I'm unsure what to make of this issue, or if it's even has origins in WatermelonDB, but I've been able to load the app without encountering the error with different simulators, but every time I enable debug mode, the error immediately pops up

info:
"@nozbe/watermelondb": "^0.19.0",
"@nozbe/with-observables": "^1.0.5",
"react-native": "0.62.2",
xcode: 11.7

Update

Interestingly, when I go to launch an iOS simulator now, I cannot even get a database.db file in the simulator directory of my filesystem. What causes the database.db file to be created? I'm thinking that the issue lies there..

Update2

Also interesting of note is that when I query for a single item from the database, I get back a big object that has information like what tables are in my schema, but I don't get the item itself. I'm not sure if this is related, and that it is an issue related to the set up

[djorkaeffalexandre]

Are you using Synchronous watermelon?
If yes, I guess it's caused by RCT_EXTERN__BLOCKING_SYNCHRONOUS_METHOD.
You can check this issue for further information: facebook/react-native#26705.

[Tycholiz]

@djorkaeffalexandre thanks for the link, but I've combed through it before and couldn't find anything relevant.

Can you elaborate what you mean by Synchronous Watermelon? are you referring to this?

If this is indeed the problem, would it be coming from the Watermelon boilerplate that I set up, or it is more in the way that the methods are being called? Disclosure: I've taken Watermelon code from a few different projects by now

[djorkaeffalexandre]

@Tycholiz nope, I'm referring for the first item of this changelog -> https://nozbe.github.io/WatermelonDB/CHANGELOG.html?highlight=sync#new-features-3, but I've read that it'll fallback to async mode when you're debugging, so it shouldn't be the problem.

[radex]

If it works -- great! nothing to worry about. But do expect error logs, because it will be trying to call synchronous methods (but should catch the error and fall back to the glitchy and slower, but working asynchronous mode)

Interestingly, when I go to launch an iOS simulator now, I cannot even get a database.db file in the simulator directory of my filesystem. What causes the database.db file to be created? I'm thinking that the issue lies there..

it's created when the database adapter is instantiated

Also interesting of note is that when I query for a single item from the database, I get back a big object that has information like what tables are in my schema, but I don't get the item itself. I'm not sure if this is related, and that it is an issue related to the set up

can you elaborate? that sounds suspicious

[Tycholiz]

synchronous mode

so it appears that when I enable synchronous mode, I get the "uh-oh error".

db file creation

I have confirmed that the adapter is getting correctly instantiated, as I am able to console.log out its contents. However, if this is the point that the database file gets created, I would also expect to see a database.db file in the simulator app directory; a location similar to this:
~/Library/Developer/CoreSimulator/Devices/ABC4D452-3A69-42A6-B9FF-99F764A6DC1C/data/Containers/Bundle/Application/AB0A0121-20BB-496D-B1DC-EC7D7FD81FB4/

However, the database file is not getting created. Yesterday through my experiments of trying out different simulators and throwing Xcode into the mix, I was sometimes able to find that database.db file, but I have not yet been able to pin down the conditions under which it gets created.

odd object from queries

this is the object I was talking about:

Here are the steps I went through to make the query happen:

1. provide the database to the app using DatabaseProvider
2. instantiate (?) a database with the useDatabase hook
3. set a new variable with const nuggets = database.collections.get('nugget')
4. console.log out nuggets (the result of which you see above)

• I'm not even sure if at this point I am able to save anything to the local database (seeing as I cannot find that database.db file to be able to query it.

Full disclosure: If there are any pitfalls that exist in a library, I am the type of developer that is going to stumble into them. It's very possible that I'm doing something very wrong, but I think having that bit of extra clarity on understanding on how things are generally working under the hood goes a long way to be able to use the library effectively. If I am able to get this library to work in my app, I'd be eager to write up some documentation to help clarify these sort of things.

Update

I have been able to successfully create a record, yet I still cannot find the database.db file. So where are my records actually being saved? (just to confirm, that object I was describing before has the adapter information, and it correctly says SQLite is being used)

[radex]

so it appears that when I enable synchronous mode, I get the "uh-oh error".

as we established, you're not going to get synchronous mode when doing remote debugging.

However, if this is the point that the database file gets created, I would also expect to see a database.db file in the simulator app directory; a location similar to this:

Look at Xcode logs, it'll print the path to the DB.

set a new variable with const nuggets = database.collections.get('nugget')
console.log out nuggets (the result of which you see above)

that looks correct. You're not making a Query, you're just getting a Collection object.

[Tycholiz]

Here is the log from Xcode when I start up the app. Unsure if any of those connection refused messages are a cause for concern, but I do not see the location where the database is allegedly being saved. Is there some extra step I need to take?

My current method of finding the path where my app is located is by opening up a process manager and finding the running process of my app name. It only yields one result, so I'm confident this is what I'd be looking for. I'm curious to know why there would be no database.db file there, despite me seemingly being able to persist items to the database. Any ideas?

[radex]

but I do not see the location where the database is allegedly being saved

in synchronous: false mode too?

Unsure if any of those connection refused messages are a cause for concern

no.

[Tycholiz]

yes I am running with synchronous: false

for reference, here is my watermelon db config:

const adapter = new SQLiteAdapter({
    schema,
    dbName: 'neverforget', 
    migrations,
    synchronous: false,
})

export default new Database({
    adapter,
    modelClasses: [
        Nugget,
        Bucket,
        NuggetBucket,
    ],
    actionsEnabled: true,
})

[radex]

dbName: 'neverforget',
I'm curious to know why there would be no database.db file there

this is probably a dumb question, but did you look for a file named neverforget in your app's Documents folder?

[Tycholiz]

yes, I should have clarified that I'm only saying database.db to make it easier to understand for you and all future readers of this thread.

within the application folder, there is only:
BundleMeta.plist
neverforget.app (a directory)
.com.apple.mobile_container_manager.metadata.plist

There is nothing interesting within neverforget.app

But also interesting is that there is no Documents folder at all within the app.

Am I correct in that this should be the correct path?:
~/Library/Developer/CoreSimulator/Devices/9EB018E4-FE6E-4463-B2BD-1CAD40DB63BF/data/Containers/Bundle/Application/15DC7ACF-7F05-46D1-AC89-21BE4B052A61/

[Tycholiz]

Regarding the large complex object I pointed out earlier, I was actually mistaken of the particular instance I had meant to disclose. The object resulted from running the following code:

        nuggetsCollection.find('2bxjj73vkd80vthe')
            .then(nugget => {
                console.log('nugget:', nugget)
            })
            .catch(err => console.log(err))

and here it is, truncated:

{ _isEditing: false,
  _isCommitted: true,
  _hasPendingUpdate: false,
  _hasPendingDelete: false,
  __changes: 
   { _isScalar: false,
     observers: [],
     closed: false,
     isStopped: false,
     hasError: false,
     thrownError: null,
     _value: [Circular] },
  _subscribers: [],
...

I'm not at all sure if this is supposed to be how it looks. Alas, I'm sure I could enhance the documentation if I had a better understanding of what was going on here. Interestingly, I am able to access a property on the object (nugget.title), yet I don't see a title property on nugget when I console.log it

[Tycholiz]

I think it's also interesting to point out that I acked for neverforget.db (and other variations) in the root of all simulators ~/Library/Developer/CoreSimulator/Devices/, and my results turn up nothing.

Is it possible that I'm not even using SQLite, even though the objects that get logged to the console clearly show underlyingAdapter: SQLiteAdapter? I'm having a difficult time understanding how I am able to persist and query data, and yet not be able to find any instance of a database by the methods we've tried already

[radex]

{ _isEditing: false,
  _isCommitted: true,
  _hasPendingUpdate: false,
  _hasPendingDelete: false,
  __changes: 
   { _isScalar: false,
     observers: [],
     closed: false,
     isStopped: false,
     hasError: false,
     thrownError: null,
     _value: [Circular] },
  _subscribers: [],
...

this indeed looks correct. see: https://github.com/Nozbe/WatermelonDB/blob/master/src/Model/index.js

Interestingly, I am able to access a property on the object (nugget.title), yet I don't see a title property on nugget when I console.log it

Probably because title is not a stored property but something defined via @field decorator — am I right?

---

Here's what I would do:

https://github.com/Nozbe/WatermelonDB/blob/master/native/ios/WatermelonDB/Database.swift#L21 -- put a breakpoint here in Xcode, and run the app. You should see the debugger break at this point… and then you can inspect path using po path in the lldb console. (Please look up a basic Xcode debugging tutorial if you're not familiar with it) -- or in the left half of the bottom pane if you enable it you'll see values of all variables.

[Tycholiz]

Thanks for the recommendation. I have actually decided to put offline implementation onto the backburner for now until the MVP is done, then I will revisit it. Until then, I am going to close this.

Thank you all for input, and I look forward to using WatermelonDB and contributing!