Strong typing and more idiomatic API

[oliverjanik]

Thanks for all the work on this library. I like it so far.

Do you have any plans to provide more idiomatic API with strong typing? As it stands everything takes in an object.

Another example is optArgs which is string based. Why not have a class with all the supported properties e.g. InstertArgs that you can pass into .Insert() call?

[bchavez]

Hi @oliverjanik ,

Thanks for your feedback. I really appreciate it. I'm really glad you like the driver so far.

By the way, were you able to get the solution to build in VS? I saw your question on Gitter. ICYMI, just run build restore before opening up the VS solution and the ConfigureAwait analyzer should be picked up. Also, you might have already found it but there's a wiki page here for driver development.

Idiomatic API

I do have some additional ideas and plans already in the pipeline to make the driver more idiomatic in .NET. One of them is providing a LINQ to ReQL provider. I currently have a local branch that I've been using to start work on a LINQ to ReQL provider. The LINQ to ReQL provider can provide a more idiomatic approach to querying RethinkDB. It's probably as idiomatic as it gets :sparkles: :smile:. Here's part of the conversation I had in #driver-dev on the slack.rethinkdb.com channel when I got the first LINQ to ReQL query to work (sorry for the screen grab, the Slack URL didn't work for archived messages after a certain date):

---

---

There isn't much there in my local branch for the LINQ to ReQL provider except for a rough draft of the overall arching architecture of the LINQ provider that got the example above working. Development on this driver is mostly on my free time and I don't have an immediate need for the LINQ provider in my current projects. So, it's hard to say when it will be ready.

Strong Typing

I agree with you there. There could be some improvements in this area. Specifically, regarding OptArg there is an open issue in the Java driver for this. See: https://github.com/rethinkdb/rethinkdb/issues/5184.

I'd like to see if there's any movement in the Java driver first. The key driving force for me is maintainability right now since this is all mostly on my free time. So, I think any solution regarding strongly typed OptArgs would probably involve the same code generation technique similar to how the ReQL C# AST is generated. The last conversation I had about this with some of the RethinkDB engineers is that OptArgs have a pretty high change rate relative to other parts of the driver. This is one of the reasons I've kept them as strings for now.

I hope that helps.

Thanks, Brian

[oliverjanik]

Thanks for the comprehensive reply. I understand you want to follow java driver closely. It looks like even the Java driver is not very strongly typed and idiomatic, yet.

I'm just hoping this driver can drop the shackles in the future :-).

Good work on the Linq provider I'll check it out.

[cecilphillip]

Whoa! Nice work with the LINQ to ReQL implementation ...

Now that's something you should blog about

[jrote1]

@bchavez I am planning to start working on a Linq provider for this, is there anything you had in mind in terms of API before I start? I have some prior experience with Linq providers and would be really helpful to be able to use Linq in my current project

[bchavez]

Hi @jrote1 ,

I didn't have much in terms of an API yet. Mostly I got started with Remotion.Linq Re-Linq to help ease the process.

I've pushed what I have so far in the relinq branch here. Excuse the total mess. :cactus:

You can check it out and continue the work or start over if you come up with a better solution.

Here's where I was going with it... so in terms of guidance, the LINQ provider should simplify expressions like this:

.Where( f => f.Foo == 1+2+4 )
.Where( f => f.Foo == 7 )

This is one reason why I chose to use Remotion's Re-Linq since it helps greatly with this. Especially with expressions involving DateTimes and such.

Also, at some point Marshall Cottrell and I envisioned the LINQ provider leveraging attributed classes similar to:

[ReqlTable("mydb", "mytable")]
public class Person
{
    [ReqlPrimaryKey]
    public Guid Id { get; set; }

    public string FirstName { get; set; }

    [ReqlIndex("lastname_ix")]
    public string LastName { get; set; }
}

And have the LINQ provider automatically pick up and recognize attributes and add .OptArg("index", "lastname_ix") to the underlying query terms appropriately. If you can find a better way or an alternative API syntax with the LINQ provider, feel free to make it happen. I'd only suggest giving us a head's up so we could take a look and discuss some of the API before committing to it. :+1:

Right now, the relinq branch has a hard binary dependency on Remotion.Linq. AFAIK, Remotion.Linq is not compatible with .NET Core yet. So, finally, the last step would be to import all the source code from Remotion.Linq under something like RethinkDb.Driver\Linq\Remotion and fix up any cross-cross platform issues in their source so that our driver can ultimately run on both .NET Full and .NET Core.

Also, if at all possible, I hope we could encourage taking the most maintainable route possible in whatever design choices we make. The burden and cost for me to maintain a high-quality driver + documentation + support is slowly creeping up. Most likely, I'll be maintaining the source for the foreseeable future so the simplest and most maintainable approach would be super awesome. :smiley_cat:

If you have any questions about the driver I will do my best to help in anyway I can.

Thanks, Brian

EDIT: From Slack:

marshall007 [5:21 PM] @bchavez: hey! from what I recall it was: [ReqlTable(name, db, options)], [ReqlPrimaryKey(name)], and [ReqlIndex(name, options)] [5:22] names would all be option and would default to the class/property name [5:26] the only other idea I remember discussing was providing utilities to generate the db/table schemas from your data models. similar to the EF code first stuff

[marshall007]

And have the LINQ provider automatically pick up and recognize attributes and add .OptArg("index", "lastname_ix") to the underlying query terms appropriately.

@bchavez to add to this, in thinky I added support for automatically optimizing object-based .filter() queries to .getAll().filter() (see neumino/thinky#126), which is pretty handy. You might consider doing the same thing once the ReqlIndex attributes are in.

[jrote1]

@marshall007 Hi currently the Linq provider will use indexes when properties are decorated with PrimaryIndexAttribute or SecondaryIndexAttribute when using Where or OrderBy. Give it a go if you like and if you have any problems raise an issue and I will look into them. Just a note currently it will not optimize Where to Between.