issues-336 Init array support

[ikrivosheev]

PR Info

• Closes https://github.com/SeaQL/sea-query/issues/336

Depends:

• https://github.com/SeaQL/sea-query/pull/387

Adds

• [x] Support Array

Breaking Changes

• [x] Drop feature postgres-array

Todo:

• [x] Implement for all other types
• [x] Fix examples
• [x] Fix tests
• [ ] Add documentation
• [x] Fix postgres driver
• [x] Fix sea-query-driver
• [x] Fix sea-query-binder
• [ ] Remove todo from CommonQueryBuilder
• [x] Add methods for work with new Value items

[ikrivosheev]

@Sytten @billy1624 @tyt2y3 This is Draft PR for add support Array type

[Sytten]

Related to https://github.com/SeaQL/sea-query/issues/336

This is basically proposition #2 and it looks well done (great job @ikrivosheev!). I think it's a decent way to move forward pending a larger refactor as discussed with proposition #3.

[ikrivosheev]

I have one question. How can we work with array of arrays?

[billy1624]

@Sytten, have any experience working with array of arrays in PostgreSQL?

For me, I don't like the idea of having array datatype in database, let alone array of arrays lolll

We might want to leave array of arrays for later?

[billy1624]

The code looks nice! @ikrivosheev please continue implementing array support :) Thanks!!

[Sytten]

@billy1624 I don't think array of arrays is a thing in postgres. I never saw it supported anywhere in any-case so no worries there.

I would say custom types are much more common (these days it is mostly for enums and composite keys) and arrays of custom types do happen once in a while. It is not as common now that json support is very well done, but it can happen and so it should be supported at some point.

[ikrivosheev]

@Sytten I add support for array to sea-query-binder.

[ikrivosheev]

@Sytten hello! I have done some features:

1. Add support for array in sea-query-binder
2. Add support for array in sea-query-driver
3. Add support for array in driver/postgres
4. Tests are passed!

Can you review this part?

[Sytten]

Will do tomorrow, pretty busy today. Ping me again if I forget

[billy1624]

I don't have much to say at the moment, it is headed in the right direction for this support. That being said I am not sure we really want to do this in the current state of things. Personally I would move to a trait based system instead of the enum and I would consolidate the driver/binder mess before thinking about array support.

In the long run, I support adding a Value trait and redesigning the Value API from ground up. However, at the moment I think we can extend the functionality based on (current) Value enum.

Any comments? @tyt2y3

[ikrivosheev]

I don't have much to say at the moment, it is headed in the right direction for this support. That being said I am not sure we really want to do this in the current state of things. Personally I would move to a trait based system instead of the enum and I would consolidate the driver/binder mess before thinking about array support.

In the long run, I support adding a Value trait and redesigning the Value API from ground up. However, at the moment I think we can extend the functionality based on (current) Value enum.

Any comments? @tyt2y3

I think about the current implementation and find it bad. A lot of code... Very hard to maintain.

@billy1624 if you want, I can create PR with my peace of code.

[tyt2y3]

It's quite a lot of boilerplate indeed, and I have the same concern over maintainability.

ValueTrait would help, but we should keep the primitive types in a enum, where i64 (and anything smaller than 8 bytes) should reside on the stack. For Object types (which we Boxed), we can probably use a fat pointer Box<&dyn ValueTrait> such that it allows users to impl that on their own.

What do you have in mind @ikrivosheev ?

[ikrivosheev]

I close this PR. Better solution is: https://github.com/SeaQL/sea-query/pull/467