Add hasFields, Keys, Pluck, Values and Without manipulations #52

[Th3Mouk]

Purpose

#52

Open Questions and Pre-Merge TODOs

• Add tests suite

Solution

Theses operators aren't tested yet

[Th3Mouk]

@tbolier I'm totally stuck on operators implementation, i don't get the global logic of the implementation. Especially on the hasFields one.
The try is about:

r.db('test')
  .table('tabletest')
  .filter(r.row.hasFields('number'))

And the implementation is in HasFieldsTest

The problems are:

• row() fonction must be without parameters (i think it's cool now)
• filter() operator is not well documented

I don't understand if the HasFields operators must return a Row, a QueryInterface, himself, or something else.
If I must create a ManipulationTrait or use the Row classes to add the method. And why here in FilterByRow my manipulation query (HasFields object) is null.

I'm afraid theses problem impact the date operators implementation too. I need to start the dev of a new API and without them I probably will switch to another driver.

[tbolier]

Great work, will you add the missing unit tests or do you need help with that?

[tbolier]

Can you remove this unused property?

[Th3Mouk]

Yeah please I need some explanations to finish those operators

[tbolier]

@Th3Mouk I will code along in this pull request to help if that is okay with you?

I have some comments ready in the pull request review, but I think participating makes it a little easier.

• For the filter implementation, check the current GetFieldLogic as example. What are your the issues you are running into at the moment?
• The row parameter can be optional, that's no problem. I see you already worked that out.
• The return types can differ per implementation, so the return type for row()->hasFields() can be different than get('ID').hasFields(). Traits are only there to make code reusable, if we cannot reuse it, because the logic is different, there is no issue in duplicating some code / even traits. Of course we try to keep it as clean, as less complex, as less code duplication as possible, but this should not block our ease of implementation. Choose for the easy route via duplication, and later we can always slim it down again, if we see we have blocks of duplicate codes.

I will clone your branch and get the coding in this week.

[tbolier]

Isn't the ? is obsolete since null probably will never be passed?

[Th3Mouk]

No problem ! I prefer a few exemples to long explanations

[tbolier]

Hey @Th3Mouk

I've fixed the hasFields manipulation command for Table and Row by creating two objects. The different between a Table query with hasFields is that the table query should be nested in the hasFields array, like you had implemented initially. For the Row implementation that query should never be nested, it's just a command that gets nested within the FilterByRow command, since it's passed as parameter there. Very confusing, but please look at my commit added to this PR:

212b333

This is what I meant with code duplication is fine, if the implementation differs. We do not need to put anything in traits if we have different implementations.

Does this make sense to you?

[tbolier]

@Th3Mouk For Keys, Pluck, Values and Without the implementation was fine, only a nesting query fix and returning concrete types for auto completion at client.

[tbolier]

@Th3Mouk I am planning to merge this, are you happy with the outcome and feedback, and do you agree I will merge this?

[tbolier]

A good tip to debug is to check the XHR request headers from the admin rethinkDB panel, this will show you the raw JSON query send to RethinkDB, I usually compare this to the PHP raw query that I will copy paste from xDebug.