Review to tag

[Aaron Piotrowski]

I'd like to tag a version of this library so I can tag new versions of postgres and mysql.

[Niklas Keller]

Maybe we should add ResultSet::toArray / ResultSet::getAll as a convenience method? Otherwise, I think I already reviewed the library and haven't found anything I'd change. I didn't review the code more closely, but rather the interfaces.

[Aaron Piotrowski]

@kelunik I think those should be separate functions. Perhaps as Amp\Iterator::toArray() and getAll().

Right, my concern is the interfaces more than the code. Code issues we can always fix later.

If @prolic thinks it looks good I'll tag then.

[Sascha-Oliver Prolic]

On it, I'll review right now

[Sascha-Oliver Prolic]

PooledResultSet

in Mysql: public function getFields(): Promise
in Postgres: public function getFieldCount(): int

Is it possible to unify this and have both methods in SQL interface?

[Sascha-Oliver Prolic]

Statement

in Mysql: public function getFields(): Promise; - not possible to add to postgres?
public function bind($paramId, $data); - not possible to add to postgres?
public function reset(): Promise; - not possible to add to postgres?

[Aaron Piotrowski]

getFields() could potentially be part of the interface, but the information returned is unlikely to match, so I hesitate to make that part of a common interface.

[Sascha-Oliver Prolic]

getFields() could potentially be part of the interface, but the information returned is unlikely to match, so I hesitate to make that part of a common interface.

Okay

[Aaron Piotrowski]

Statements in postgres do not support binding values, so bind() and reset() are not necessary.

[Sascha-Oliver Prolic]

\Amp\Mysql\DataTypes - can we move that to Internal namespace? I don't think it should be used in userland.

[Sascha-Oliver Prolic]

other then what I noted above, I can't find anything more. So if getFieldCount() can be added to SQL, would be fine, otherwise just tag it.

[Aaron Piotrowski]

DataTypes can be used when examining values returned from getFields(), etc. So there is reason to have it in the public namespace. The functions are unlikely to change anyway, so I'm not concerned about it being in the public API.

[Niklas Keller]

@trowski Amp\Iterator::toArray() won't support the custom parameter to getCurrent(). If we don't want convenience methods, maybe we should remove the fetch type, too? After all, a consumer will likely convert them to a proper value object anyway.

[Aaron Piotrowski]

Right, forgot about the fetch type parameter. Well a function in this library would do as well.

Generally the fetch type isn't needed, however if a result has fields with the same name it can matter. Do we care about this case? I've never used it, and queries can always alias field names.

[Niklas Keller]

Right, I'd always go with aliasing in that case, so let's drop it?