The main motivation for this is that building error messages via string
concatenation is tedious and makes it hard to judge what the actual message
looks like when there are a lot of parts being inserted, to the extent that
I've been tempted to leave out some potentially useful information because the
code was getting unwieldy.
It also has some small functional benefits: bools are printed as true/false
rather than 1/0, and it is optimized for minimizing the compiled size.
Currently it cuts ~30 KB off librealm-object-store.dylib even with the addition
of new functionality.
constructors.
This avoids having to repeat the move constructor's logic in the move
assignment operator, and allows the copy assignment operator to compile
despite `TableViewBase`'s missing copy assignment implementation. the
copy assignment implementation can be defaulted once `TableViewBase` is
fixed.
The custom implementation was an attempt to ensure that
`m_has_used_table_view` and `m_wants_background_updates` had appropriate
intial values. Thomas pointed out that we can remove the reliance on the
initial values by ensure that `prepare_async` sets
`m_wants_background_updates`, removing the need for a custom copy
constructor.
* object-store/master:
Make Realm::is_closed() work on read-only instances
Fix for object store build issues on Android
Implement commit helper and realm notifier for Android (#69)
Build both dynamic and static libraries.
moving pegtl dependency as step 1 in install doc
update docu (install procedure)
`Realm`, and moving from a `Results` to not result in a use-after-free.
The compiler generated move-assignment operator resulted in `m_notifier`
being assigned to without first calling `CollectionNotifier::unregister`.
This left a retain cycle in place, causing the `Realm` and other objects
to leak.
`ResultsNotifier` keeps track of which `Results` it should update when a
new `TableView` becomes available. When `Results` move-assignment
operator and move-constructor transfer ownership of the
`ResultsNotifier` to a new instance they also need to update its target
so it won't attempt to update the moved-from `Results`.
The Xcode project generated by CMake doesn't create the dylib when built
as the dylib target does not contain any source files. Adding an empty
placeholder .cpp file to the target is sufficient to convince Xcode to
produce the dylib.
* Implement commit helper and realm notifier for Android
* Remove non-existent include
* Shut down the current instance when move-assigning
* Only use Android logging when on Android
* Cleanup realm_ptr when it hasn't been sent over the pipe
* Assed that WeakRealmNotifier is closed on the thread it was created on
* Typo
* Fix syntax error
* changes after code review
* Use the proper preprocessor definition for Android
* Pass the correct address to write(2)
* Explicitly handle looper events
* changes after code review
* Do not return after handling ALOOPER_EVENT_HANGUP
* Handle HANGUP after INPUT
This bug would only happen from Chrome debug mode, where consecutive calls would crash the app because the m_objects iterator would be in a bad state. This method is faster anyways.
The dynamic library makes it easy to verify that there are no linker
errors when building the object store, while the static library is
easier for a binding to consume.
This also tweaks how the library targets are defined to ensure that
other CMake projects that pull in the libraries automatically get the
right include paths and link to the appropriate libraries.
When deleteAll() is called on a Realm, it calls clear() on all of its Tables, which seems to not update TableViews unless they are synced. The is_row_attached(row_ndx) method still returns true otherwise. A workaround is here until that is fixed.
Fixes#434
File::AccessError is now thrown for all file-related exceptions which don't
have more specific types (rather than std::runtime_error), which requires some
changes to how exception messages are built when translating them to get nice
results.
Also add `Realm::write_copy()` which just wraps `Group::write()` with error
translation.
When deleteAll() is called on a Realm, it calls clear() on all of its Tables, which seems to not update TableViews unless they are synced. The is_row_attached(row_ndx) method still returns true otherwise. A workaround is here until that is fixed.
Fixes#434
When deleteAll() is called on a Realm, it calls clear() on all of its Tables, which seems to not update TableViews unless they are synced. The is_row_attached(row_ndx) method still returns true otherwise. A workaround is here until that is fixed.
Fixes#434
Moved it up one level since it references the whole source tree inside the src/ directory. Added the functionality to run Node tests from Xcode on the existing RealmNode target.
We don't track insertions and deletions for tables that are merely linked to by
tables actually being observed (for performance reasons, since we don't need
that information), but the check for that was missing in one place. This would
be merely a slowdown rather than a crash, but deletions.add_shifted() can
overflow size_t if the passed-in index represents a newly inserted row and the
check for that didn't work due to not tracking insertions for the table.
The only remotely realistic way to actually have size_t overflow is to have
previously cleared the table (the table clear instruction does not include the
old size of the table, so it just marks {0, SIZE_T_MAX} as deleted).
Fixes#3537.
Skip doing any checking at all if none of the tables reachable from the root
table have been modified (which can happen if the table version was bumped due
to insertions, unrelated backlinks, or unlinked-to rows being deleted in linked
tables).
Add cycle checking rather than relying on the max depth to handle it, as the
worst case was O(N^16) if the cycle involved a LinkList of size N.
Track which rows have been confirmed to have not been modified.
Cache the information about the links for each of the relevant tables as
checking the table schema can get somewhat expensive.
If there are multiple Realm instances for a single file on a single thread due
to disabling caching we need to actually deliver the results to the appropriate
SharedGroup for each notifier rather than delivering them all to the first one.
Even if the new TV has the same rows as the old one, we need to hand it over to
the destination thread to bump the outside version of the destination thread's
TV to avoid rerunning the query there.