Fix issue with lb4 id different to int

[frbuceta]

Introduce a new property-level metadata useDefaultIdType which can be used to prevent juggler from replacing PK property type provided by the user with the default PK type supplied by the connector.

See loopbackio/loopback-next#3602

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• Commit messages are following our guidelines

[slnode]

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

[dhmlau]

@frbuceta, could you please add some tests? Thanks.

@slnode test please

[bajtos]

Thank you @frbuceta for the pull request. As @dhmlau commented, we need you to include some tests to verify this change.

[frbuceta]

@bajtos @dhmlau Yes, tomorrow without fail I do

[frbuceta]

In which file should I create the tests? /test/datasource.test.js?

[bajtos]

Here are few existing tests related to id injection, I think it's a good place where to add a new test for your change:

https://github.com/strongloop/loopback-datasource-juggler/blob/8b75767daf0562b084d22336037efd45058d2b15/test/loopback-dl.test.js#L641-L673

loopbackio/loopback-next#3602 describes a problem with auto-generated id values when don't have the type configured by the connector. To be sure that the proposed change is actually solving the high-level problem, I'd be good to have a test that's calling create and find methods and verifies that the auto-generated values is preserved in the string form. The tricky part is how to implement auto-generated UUID values using our in-memory connector, because we don't want to use SQL. Can we mark the column as auto-generated (to trigger the problematic code path) and yet supply a custom id value when creating a model instance? At minimum, this probably requires setting forceId: true in model settings.

Such test can go to test/manipulation.test.js, this way it will be executed for all database connectors.

[frbuceta]

There are some tests that already contemplate the type id String

[frbuceta]

Ready, @bajtos can you take a look?

[frbuceta]

Without the 'useDefaultIdType' it works exactly the same ...

[bajtos]

I pushed a commit 8a58239 that fixes the test to fail on current master and pass with your changes in place.

Let's see how it works when executed against different SQL/NoSQL connectors.

[dhmlau]

@slnode test please

[frbuceta]

@bajtos The tests fail and I can't look at the log

[bajtos]

Ouch.

Here is the log for MySQL - it looks like the new flag is not honored and the primary column is created with numeric type (instead of a string/varchar).

   1) juggler-v4
        manipulation
          upsertWithWhere
            preserves custom type of auto-generated id property:
      Error: ER_TRUNCATED_WRONG_VALUE_FOR_FIELD: Incorrect integer value: 'custom user id' for column 'id' at row 1

Similar problem on PostgreSQL:

1) juggler-v4
        manipulation
          upsertWithWhere
           preserves custom type of auto-generated id property:
      error: invalid input syntax for integer: "custom user id"

[bajtos]

This is tricky. The most important thing to change is the model name. The original test is using an existing table/collection created for User model defined elsewhere with connector-specific PK type. I modified our new test to use a different model name and run automigrate to create a new table/collection in the database.

I am not sure if all SQL connectors support auto-generated PKs with non-numeric type, I am trying to disable generated flag after useDefaultIdType has been applied. It's a bit hacky, I wish there was a better solution 🙈

See 67019c4 for more details. Let's wait for CI results now 🤞

[bajtos]

@slnode ok to test

[bajtos]

Looks like my latest commit made the test to pass for SQL too.

@frbuceta are you fine with the current patch? If yes, then we can clean up the git history (preferably preserving my co-authorship via https://github.blog/2018-01-29-commit-together-with-co-authors/) and proceed to land this pull request.

[bajtos]

We need to clean up git history before landing.

[frbuceta]

Parece que mi último commit también hizo que la prueba pasara por SQL.

@frbuceta, ¿estás bien con el parche actual? En caso afirmativo, entonces podemos limpiar el historial de git (preferiblemente preservando mi coautoría a través de https://github.blog/2018-01-29-commit-together-with-co-authors/ ) y proceder a aterrizar este tirón solicitud.

Yes, I am in favor, in any case it is an honor to work with you on this

[bajtos]

Landed, thank you for the contribution 🎉