Instead of rethrowing the JavaScript error emitted from a callback function, we should instead pass it to `node::FatalException`.
Callbacks are employed when there is no other JavaScript frame on the stack prior so rethrowing the JS error as a C++ exception is not going to propagate the error back to JavaScript. `node::FatalException` will raise the `uncaughtError` event on the `process` object , print the error and stacktrace, and alert the debugger is there is one attached. This would make our async callbacks behave consistently with Node’s own async callbacks such as `setTimeout` when encountering an error.
* Make it possible to assign a List or Results to a List property.
The change made in #1069 to improve error messages when values of
incorrect types were assigned to a given property was being too
narrow in the types it accepted for list properties, allowing only
arrays. Lists and Results are now accepted once more.
* Update CHANGELOG.md
* Add support for linkingObjects
* Test linkingObjects
* Borrow names helper from list tests
* include computed properties when serializing the schema for the RN debugger
* add API docs
* review comments
* Expose admin users to JS (#1100)
The JS binding used to conflate `SyncUser::is_admin()` with the user being created by calling `Realm.Sync.User.adminToken()`, but now that we expose a user’s role on the server under `is_admin()` this supposition is no longer correct.
#1097 attempted to fix one such case, but fixing it only uncovered another: in `UserClass<T>::all_users()`. I’ve gone through all the callsites of `SyncUser::is_admin()` to make sure they don’t assume an admin token user.
* [1.8.3] Bump version
* add linkingObjects method to Realm.Object
* changelog
The JS binding used to conflate `SyncUser::is_admin()` with the user being created by calling `Realm.Sync.User.adminToken()`, but now that we expose a user’s role on the server under `is_admin()` this supposition is no longer correct.
#1097 attempted to fix one such case, but fixing it only uncovered another: in `UserClass<T>::all_users()`. I’ve gone through all the callsites of `SyncUser::is_admin()` to make sure they don’t assume an admin token user.
* Do not throw when the Sync constructor isn’t there
with unified packaging it’s there all the time now
Closes#1084Fixes#996
* Fix running the sync tests when Sync is disabled
* Add and adopt `Value::is_binary` / `Value::to_binary` / `Value::from_binary`.
These methods allow conversions between `BinaryData` and the equivalent
JavaScript types without using `NativeAccessor`. Instead,
`NativeAccessor` now itself delegates to these methods.
* Have `NativeAccessor::value_for_property` and `RealmObjectClass::set_property`
verify that values are valid for the property in question.
If not, we throw an exception that includes the name and type of the
property in question.
`NativeAccessor` is changed to always hold a reference to a `Realm` and
an `ObjectSchema` in order to make this validation possible.
* Fix the Windows build.
* Remove an unused, incorrect forward declaration of a template class
named `Realm` that caused ambiguity with object store's `Realm` class.
* Disambiguate between `realm::js::PropertyType` and
`realm::PropertyType`.
* Update CHANGELOG.md
* adding ts and package.json typings
* remove DefinitelyTyped needed comments, we are hosting this ourselves
* adding licensing comments
* Added initial contribution support
Thanks @akim95
* changing year
* adding parameters
* Expand on collection typings
* update the windows pre-gyp script (#1072)
* Extract admin status from the refresh token (#1078)
* Extract admin status from the refresh token
Fixes#1063
* wire up rpc
* Make sure all callbacks enqueue on the Node.js event loop (#1079)
Fixes#1077
* Use an uncached realm instance for _waitForDownload (#1083)
Fixes#1061
* Add objectSchema method to Realm Object (#1055)
* Add objectSchema property to Realm Object
* fix
* fixes
* move typings under lib/
* changelog
* Remove the windows install check
* Node.js Win32 support
* Bring back the `REALM_HAVE_CONFIG` definition
* Download core for Windows when building
* Implement cross-platform node platform.cpp with libuv
* wip
* Make jasmine run quicker
https://github.com/jasmine/jasmine/issues/1204
* Wait for worker process to close in AsyncTests
* Cross-platform paths in tests
* Normalize path separator for forward slash on Windows
* MSVC exception voodoo
* cross-platform uv_cwd
* fix linux build
* make the prepublish script cross-platform
* Disable encryption tests on windows
* ignore vendor/realm-node
* jenkinsfile work
* Only run the prepublish script for publish and pack
* Jenkinsfile work
* Include gyp files in package
* rewrite default_realm_file_directory()
* fix React Native Android build
* delete all realm artifacts in remove_realm_files_from_directory
* bring back build environment variables
* node-pre-gyp windows
* Update CHANGELOG.md
* Add Permissions models and User Management Realm API
* docs and changelog
* fix bad merge
* add test
* fix jsdoc annotation
* rename permissions to management schema
By default, React Native projects target a minimum of iOS 7, but our projects were set to iOS 8 because previously we used a dynamic framework.
When building for an iOS 7 minimum target version, the linker would complain about thread local variables not working on iOS 7. So it was necessary to add even more checks (iOS >= 8 or OS X >= 10.7) before using native thread local variables rather than our shim.
This also changes our projects to target iOS 7 so we can catch these issues quicker in the future.
Since Code runs in Node, rather than Chrome, we need to require the `sync-request` module. The global `__debug__` object was exposed by the vscode-react-native plugin v0.1.5 for us to be able to do that.
Resolves#374
* tag 'v0.14.1':
[0.14.1] Bump version
[0.14.0-rc] Bump version
Disable "Strip Linked Product" on our static libs
Fix for linker error when building for iOS 7
There seems to a bug inside the `strip` command (or its `ld64` library) that is being triggered by some users who get this message: `Assertion failed: (0 && "need to handle arm64 -r reloc")`
It is reported that disabling this setting side-steps the issue, and we don't need any stripping done on the static library itself.
Fixes#503
By default, React Native projects target a minimum of iOS 7, but our projects were set to iOS 8 because previously we used a dynamic framework.
When building for an iOS 7 minimum target version, the linker would complain about thread local variables not working on iOS 7. So it was necessary to add even more checks (iOS >= 8 or OS X >= 10.7) before using native thread local variables rather than our shim.
This also changes our projects to target iOS 7 so we can catch these issues quicker in the future.
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
Nikola Irinchev
Yavor Georgiev
Yavor Georgiev
Mark Rowe
blagoev
Marius Rackwitz
astigsen
Maximilian Alexander
kristiandupont
Radu Tutueanu
Radu Tutueanu
Nabil Hachicha
Ari Lazier
Scott Kyle