issues-336 Init array support

[ikrivosheev]

PR Info

• Closes Query binders: Add support for postgres arrays #336

Depends:

• issues-383 Rewrite examples using sea-query-binder #387

Adds

• Support Array

Todo:

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

[ikrivosheev]

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

[Sytten]

Related to #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

[Sytten]

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.

[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: #467