Hi Jens, Further to the multiple CBL listeners, do you think there might be a problem with using port 0 to generate an ephemeral unique port number instead of hard coding port numbers?
I guess I can imagine a problem if someone closes a document on one device which is still opened on another, then re-opens that document, sync wouldn't be able to automatically continue without further network discovery to determine the updated port number to connect to. If that's the case then I'd need to either ask the user to enter in a port number per document (a terrible idea) or generate a random unused port number and store that inside the document's prefs to be used again later. Something that all devices can connect to later on. Could also be a problem if at some later time another service used that same port when the document was closed. If the document was opened then it wouldn't be able to use its stored port. Thanks, Brendan On Friday, September 25, 2015 at 2:02:22 PM UTC-6, Brendan Duddridge wrote: > > Ah that's very interesting. And ya, I didn't test those kinds of things. > Just reading and updating records (not attachments or re-indexing). I will > try that though just to see what happens. > > Yes, it would be great if you could move the database without any issues > like that. I will add that as a feature request to Github. > > > Well I think what I can do then is throw up a notification if the app > detects the document has been renamed or moved and to tell the user to put > it back and close the document first before doing that sort of thing. Plus > ample warning up front though. I think the benefits of a document based > database are just too great though to not try and give this a go. So far > I'm really enjoying being able to open multiple documents, each with their > own unique set of data. Plus it makes it easy for me to allow a user to > encrypt some databases but not others (for less private data). > > Thanks! > > Brendan > > On Friday, September 25, 2015 at 1:50:38 PM UTC-6, Jens Alfke wrote: >> >> >> On Sep 25, 2015, at 12:16 PM, Brendan Duddridge <[email protected]> >> wrote: >> >> What's strange is I did some testing with renaming the document file >> while it was open and everything still worked fine as far as database reads >> and write. I haven't started syncing things yet though. I figured renaming >> the document while it was opened would have generated some sort of database >> access error, but it didn't. Strange. >> >> >> Both ForestDB and SQLite keep the database file open and just issue >> read/write calls on the file descriptor, for the most part. That works fine >> even if the file gets moved. >> >> The things that I believe will fail, for a ForestDB-based database, are >> - Compacting a database (this creates a new db file in the directory and >> eventually replaces the old file with the new one) >> - Querying or indexing a view whose backing db file wasn’t already open >> at the time >> - Reading or creating attachments >> >> I’d like to not have these problems, but they might be hard to fix. In >> particular, ForestDB has file paths baked into its implementation at a >> pretty deep level. >> >> —Jens >> > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/375a0d1e-2a38-4f09-b345-7557d0a8f1bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
