realm / realm-dotnet Goto Github PK

As per meeting Tue 14/7 with Tim, want to get a feel for people's expectations of the API.

Worth isolating this as a separate probably Phase 2 task because DateTime seems under a lot of review. Also consider the NodaTime package and working with that.

Especially avoid using underscore_as_seperator , local variables and parametres should be camelCase, and variables visible outside a class should be PascalCase.

Also make sure other common c# conventions are used ( see http://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx)

Of course, TightDB c++ coding conventions will be used in the C++ part of the binding.

Once we're happy with the build, ensure all docs updated to match and walk people through. Consider someone who just wants to have a subset of platforms being able to remove targets safely.

.

Support the high-level logic implemented in #25

Includes the ability to set fields, of course

On Andy's first test device, Moto-G XT1033, crash running Playground
[Mono] DllImport searching in: 'wrappers' ('libwrappers.so').
[Mono] Searching for 'new_table'.
[Mono] Probing 'new_table'.
[Mono] Found as 'new_table'.
[libc] heap corruption detected by tmalloc_small
[libc] Fatal signal 6 (SIGABRT), code -6 in tid 11784 (.XamarinAndroid)

Whilst Andy has a bunch of people able to comment on LINQ and idiomatic C# stuff to say what people may expect, it will help to have a base document we use as a starter point for their review and against which we check our implementation.

Because we're specifying the primary key using the attribute [PrimaryKey] [ObjectId]we need a check to make sure this is not specified on more than one field in a given class. This has to be a runtime check. Update 2016-02-19 with more Fody knowledge, now realise we can easily do this in Fody

Alternatively, we could redesign the feature to specify the primary key with key name as parameter and make it a class-level attribute. That would take care of the problem of specifying more than one but then add a different check to ensure the field name was valid and that the field wasn't tagged with the [Ignore]

Could we stash the TableHandle directly in the RealmObject to remove the use of the table name and dicationary lookup all the time? At worst case, we could have an index of a table handle into a static array. Currently we're doing an extra dictionary lookup for every single field access.

The other repos have private sections and I assume the same rationale will occur for dotnet when we release - maybe do it now so history in the right place? Might start with #41 and cloning the Java benchmarks

NuGet packages that use the Bait'n'switch pattern to allow seamless multi-platform support

Most critical demo to people that we support Xamarin and allows direct comparison

Coming soon in iOS 9

Like XCode Plugin - see Plugins Guide

We currently rely on a custom build step which may not fit with Unity components

Assuming #32 and #33 include documenting their respective NuGet installs, this is for old-fashioned zip downloaders or people using the repo

This may be a lot harder. The Java API does the same thing we do of using a dictionary all the time to map property names to column indexes so it might be deemed acceptable for now. However, it really burns me to have a dictionary lookup on such a fundamental pathway to data access for every single object (zero-copy becomes a mockery when using objects is so expensive).

Lightweight research task to inform Tim's decision making with some technical overhead estimation

Turned this into just making some cleanups so we're not marking things for building in the wrong configs, which makes life a lot more pleasant in Visual Studio.

Original report below - Kristian can't reproduce
Running with Debug x86 configuration, IntegrationTests crashes in group_get_or_add_table with the error
An exception of type 'System.AccessViolationException' occurred in Interop.Win32.dll but was not handled in user code

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Note that this occurs with the IL problem resolved, it is apparently unrelated

Crashed on Andy's 6+ just after main screen displays.

Support full migration with a callback. Note this requires callback from C++ ObjectStore to C# to provide full application programmer control. May want some pruning by object class and by property so callback only occurs as little as possible.

See further discussion in the Schema and Migration wiki page.

Most of the configs are likely to be wrong for Release builds as only Debug has been setup.

We also need to discuss and test different optimisation levels and possibly add documentation. An implication is that performance testing such as in #41 should be functioning and we need a really good test suite to catch subtle bugs. Hopefully #46 will yield us that from the Java tests

(Andy's vague hope is that optimisation in .Net release builds won't be as fraught as picking optimisation levels in C++).

May not require any or much support but important to people doing DateTime and will be an item could generate a press release about (especially if coordinated with Java).

Task to cover minor things that come up when trying to have cleaner Windows-based build environment.

as soon as I have opened the Realm.sln in VS2015 now I get changes to
Interop.XamarinAndroid
Playground.XamarinAndroid
changing the TargetFrameworkVersion from 5.0 to 4.4
This is obviously some side-effect of my environment as I'm not editing Visual Studio.

I had very weird problems launching demo apps on Android at one point where it was saying I didn't have Build 22 installed despite all the visible target settings being for Build 21 (5.0). There have been Xamarin Studio bugs logged about the different target settings.

I think we need to agree on a minimum (maybe 4.4 or earlier) and then sweep through all settings and build environments making sure that
a) they are documented where to change and any side-effects
b) we are all using the same settings!

Prove out all transaction behaviour beyond what's been required to get simple Add and Delete working. This could be mostly about writing clever unit tests.

Test:

• Get value
• Set value
• Basic query

Run the same tests against sqlite

Remember to test binary values as this is an area where we ought to outperform sqlite.

Equivalent of XCode Plugin for Realm

As a test that our collections are working properly, Andy thinks this should allow using Linq to Objects to query the collection, which is woeful but useful for testing

Include making scripts based on common env variables such as NDK_ROOT (recommended and expected by setup such as cocos2d-x and others that build with NDK)
Hopefully should avoid dependencies so building the playground for iOS (for example) shouldn't try to build Win32.

Nunit on a 64bit windows 7 seems to have some kind of problem testing 32bit c# code that calls 32bit c++ dll's - most solutions point towards creating C# "AnyCpu" builds, and using the 32bit nunit version that is silently installed with a 64 bit nunit deployment. Still, doing this, while the unit tests run fine when not started inside Nuinit, they fail to load the dll when started inside Nunit. I'll have to investigate further, I have created 64 bit c++ dll's (and related documentation) to make sure whatever nunit solution i find is working on 64 as well as 32 bit builds.

Will speed up writing and running tests and also allow tests to be written that directly evaluate that the correct sequence of internal calls was generated.

I think this is a key test project but maybe not high priority.

It will provide Browser across platforms and demonstrate we're serious about business-style apps

It will exercise the C# interface.

Good range of tests and keeping them with just syntactic changes makes it easier for people to move between projects. Also serves as a good quality measure of completeness in the C# api.

recreated simple LINQ issue because branch naming error grabbed the former issue number. This is about the top-level LINQ stuff working with a single table

Prove support with unit tests that exercise all types.
Update the table in Types with the actual types we support.

Andy would prefer we properly support them as IDisposable, with automatic commit on dispose and an explicit Abort/Cancel Transaction call setting a flag to prevent commit on finalising

Widespread problem see http://forums.xamarin.com/discussion/24190/missing-system-objectmodel-system-runtime-assemblies may be related to combination of using a Portable Class Library with IOS using Mobile Target. The project works fine from Xamarin Studio on OS/X so for that reason has been left to Phase II. We will not be able to ship without supporting people working solely in Visual Studio.

Need to test on range of hardware - 32bit still needed pre iPhone 5S, current builds have moved to x64 assuming that was it.