Added link to polyfill repo

Thanks for pointing, removed unnecessary concatenation

I would probably, do it as: keys .filter(function(k) { return expr[k] !== null }) .map(function(k) { return exprToString(v, fn) }) but it can be a matter of preference anyway.

Notes

Jira Ticket NodeJS util package has been used for .inherits and .inspect functions. Current implementation supposes polyfilling .inherits function by created one in src/_util.js and optionally using .inspect only when we're running on NodeJS environment

How to test

No features / fixes have been introduced. Can be tested regression-wise

@erickpintor here is where FaunaTime transforms Date instance to iso string. so here is what i get

new Date(1970, 0, 1).toISOString()
"1969-12-31T21:00:00.000Z"

Notes

Jira Ticket Current driver pass a 60 seconds timeout down to the cross-fetch polyfill. However, neither whatwg-fetch of node-fetch are aware of it. They both support abort signals, though: https://github.com/node-fetch/node-fetch#request-cancellation-with-abortsignal.

Screenshots

Notes

Test "Values › date" doesn't respect timezone

Actual result

Values › date

    expect(received).toEqual(expected) // deep equality

    Expected: "{\"@date\":\"1970-01-01\"}"
    Received: "{\"@date\":\"1969-12-31\"}"

      86 |     var test_date = new FaunaDate(new Date(1970, 0, 1))
      87 |     var test_date_json = '{"@date":"1970-01-01"}'
    > 88 |     expect(json.toJSON(test_date)).toEqual(test_date_json)
         |                                    ^
      89 |     expect(json.parseJSON(test_date_json)).toEqual(test_date)
      90 |   })
      91 | 

      at Object.test (test/values.test.js:88:36)

Expected result

Test should be passed

How to test

jest --env=node --verbose=false ./test/values.test.js 

I added a WIP of sucessfully decoding omitempty structs.

This however caused another test to fail:

TestRunClientTests/TestEvalCountMeanSumExpression

Probably need someone with more intricate knowledge of the FQL language and serialization/deserialization to finish and fix this

tests and fixes for deserialization still needed, will get that one of the next days

Update: Option 1 above doesnt work either, as a pointer string field with nil value, will override and delete any existing data in the field, possibly causing unintended dataloss:

Example:

//Struct
	person := &Person{
		Name:  &name,
		Email: &email,
	}

	personObj := f.Obj{"data":&person}a
	fmt.Println(personObj.String())
  // prints: 'Obj{"data": Obj{"Name": "John Doe", "Email": "somemail@mail.com"}}'


	newEmail := "newemail@mail.com"
	personEmailOnly := &Person{
		Email:  &newEmail,
	}
	personEmailOnlyObj := f.Obj{"data":&personEmailOnly}

	fmt.Println(personEmailOnlyObj.String())
  // prints: 'Obj{"data": Obj{"Name": nil, "Email": "newemail@mail.com"}}'


	res, err := s.fdb.Query(f.Create(f.Collection("persons"),personObj))
	if err != nil {
		return err
	}
	var personRef f.RefV
	_ = res.At(ref).Get(&personRef)

	res, err = s.fdb.Query(f.Update(personRef,personEmailOnlyObj))
	if err != nil {
		return err
	}
	newPerson := Person{}
	res.At(data).Get(&newPerson)

	fmt.Println("name:",newPerson.Name," | email: ",newPerson.Email)
  // prints: 'name: <nil>  | email:  0xc013cf2480
'

In the above case, we create a person with both email and name. Then afterwards we update the persons email, having a struct that has "nil" at the Name field. This causes as the resulting value in the name field in the database to be deleted.

Update: Option 1 above doesnt work either, as a pointer string field with nil value, will override and delete any existing data in the field, possibly causing unintended dataloss:

Example:

//Struct
	person := &Person{
		Name:  &name,
		Email: &email,
	}

	personObj := f.Obj{"data":&person}
	fmt.Println(personObj.String())

	newEmail := "newemail@mail.com"
	personEmailOnly := &Person{
		Email:  &newEmail,
	}
	personEmailOnlyObj := f.Obj{"data":&personEmailOnly}

	fmt.Println(personEmailOnlyObj.String())


	res, err := s.fdb.Query(f.Create(f.Collection("persons"),personObj))
	if err != nil {
		return err
	}
	var personRef f.RefV
	_ = res.At(ref).Get(&personRef)

	res, err = s.fdb.Query(f.Update(personRef,personEmailOnlyObj))
	if err != nil {
		return err
	}
	newPerson := Person{}
	res.At(data).Get(&newPerson)

	fmt.Println("name:",newPerson.Name," | email: ",newPerson.Email)

In the above case, we create a person with both email and name. Then afterwards we update the persons email, having a struct that has "nil" at the Name field. This causes as the resulting value in the name field in the database to be deleted.

Another update on this issue, with details on a use case where pointers are not preferable is when updating existing structs:

Say I have a struct as follows

type Person struct {
	Email string `fauna:"email"`
	Name int `fauna:"name"`
}

Lets say I have strictly ensured that these columns are never null, and therefore I prefer to treat them as strings rather than pointers

Now I want to update a struct and change the email of a person. For example because I received a put request from the user. If this put object contained only the email, I would do the following:

If I pass in the customer struct like so:

myPerson := Person{Email: newEmail}

res, err := faunaClient.Query(f.Update(ref,&myPerson))

this would cause the Name field in the database to be overwritten with "", which is not I what I want.

Now am stuck with two options:

1. model the fields as nullable, even though they are not nullable and never have zero values. Which causes we to introduce unnecessary nil checks in the rest of the code.
2. manually create the FQL query for only updated a subset of the fields. This might be easy for the above struct, but imagine a large struct with hundreds of fields and nested objects where I only want to up date a single field, then it would be a tedious proces..

Implementing omitempty option elegantly solves this by never serializing and transmitting values that have zero values.

Sorry about that! I meant reverting back the faunadb package to 3.0.0.

In my case, after switching back to npm 3.0.0 the wrangler-cli can't even execute publish anymore. @jessepmason what OS are you on? Is it really npm v. 3 that works for you?

@faunaee Hi Ewan, thanks for your reply. Let's say I wanted to bulk create records. I attempted a loop create:

# for row in data:
    #     result = client.query(
    #         q.create(
    #             q.collection(collection_name),
    #             {
    #                 "data": row
    #             }
    #         )
    #     )

This worked, but for 100000 rows - is completely impractical. I'm perhaps bending FaunaDB to our whim, but how could a Lambda() work for this scenario? We have q.lamda_ but also pythons inbuilt lambda expressions...which do we use when and where? It's just not clear.

@asencis When reading data from a collection or index you can use the built in lambda function as below.

data = client.query( 
              # Maps over an array or FQL page and calls an expression/lambda on each item.
              # In this case, we are calling q.get on each item returned from the 2nd parameter’s q.paginate.
               q.map_(
                   # q.get takes a document’s Ref and retrieves the entire document.
                   # Refs are similar to primary/foreign keys and serve as unique pointers to documents.
                   # q.index returns the Ref for an index. Note that all entities in FaunaDB are documents and have Refs.
                   # q.match takes the ref of an index, along with search parameters, and returns something called a SetRef.
                   # Finally, q.paginate takes a SetRef and returns a page with iterable data.
                   lambda x: q.get(x),
                   q.paginate(q.match(
                       q.index("products_by_category"), category)))   
                   )

The new documentation site for go (pkg.go.dev) does not detect the LICENSE file correctly, causing documenation to not be displayed.

Missing docs: https://pkg.go.dev/github.com/fauna/faunadb-go/v3/faunadb

The License is MPL-2.0, but somehow pkg.go.dev does not detect this.

More info: https://pkg.go.dev/license-policy