Closed terales closed 6 years ago
Hey,
Sorry for my late answer :(
I actually thought about this when I started out and I'm not crazy about the idea. Basically you are revealing how thin a wrapper this is, which means you end up with a weird interface.
Check out the very last example in the readme where I use the inFunc
, that should solve your problem. If not, please let me know :+1:
So the idea is to write a wrapper like this:
function execWithNamedParams(array $params) {
return $params;
}
// Call it like this:
$repository->getPaymentsExample(['from' => $from, 'to' => $to]);
And use it everywhere like:
-- name: getPaymentsExample inFunc: execWithNamedParams
SELECT * FROM payments AS p WHERE p.from = :from AND p.to = :to
Did I get you right? Would you like a PR to add this example to the README?
Again, sorry of the late reply.
No. the idea is to not use named parameters in the function call. You would (probably) never do that with a normal repository. I'd go something like this:
function nameFromAndTo($from, $to) {
return ['from' => $from, 'to' => $to];
}
$repository->getPaymentsExample($from, $to);
with a query like this:
-- name: getPaymentsExample inFunc: nameFromAndTo
SELECT * FROM payments AS p WHERE p.from = :from AND p.to = :to
now you can refactor your query all you want, without breaking stuff. And your outside api looks like a normal repository :)
Thanks, got it!
Would you accept a PR which would document thin question in README?
On Mon, Feb 19, 2018, 10:38 AM Jesper Skovgård Nielsen < notifications@github.com> wrote:
Again, sorry of the late reply.
No. the idea is to not use named parameters in the function call. You would (probably) never do that with a normal repository. I'd go something like this:
function nameFromAndTo($from, $to) { return ['from' => $from, 'to' => $to];}$repository->getPaymentsExample($from, $to);
with a query like this:
-- name: getPaymentsExample inFunc: nameFromAndToSELECT * FROM payments AS p WHERE p.from = :from AND p.to = :to
now you can refactor your query all you want, without breaking stuff. And your outside api looks like a normal repository :)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nulpunkt/yesql-php/issues/5#issuecomment-366620685, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1Of--_YdNJxrqcCf8Q6nSKJlIL4cH7ks5tWTMWgaJpZM4R3yH8 .
Absolutely! :)
Also, good ideas as to how I can improve the documentation is more than welcome. The readme is getting longer, so it would be cool with ideas on how to improve it!
Thanks, I'm busy now, but I'll prepare PR this week.
Also, good ideas as to how I can improve the documentation is more than welcome. The readme is getting longer, so it would be cool with ideas on how to improve it!
Moved this conversation into the separate issue: #6
Awesome, thanks!
I love the way you referenced static method. In production we have something like this:
class User {
__constructor($pdo) {
$this->queries = new Nulpunkt\Yesql\Repository($pdo, "my-queries/queries.sql");
}
public static function toAddParams(User $user) {
return ['id' => $user->id, 'name' => $user->name];
}
public function add($user) {
$this->queries->insertObject($user)
}
}
-- name: insertObject inFunc: User::toAddParams
insert into test_table (id, something) values (:id, :something)
That is awesome! :)
@terales Hey man, I got tired of creating inFunc's, so I've added (what I consider) better support for named parameters :)
Awesome! How can I use it? It's not obvious from the PR.
Can you update an example, please? https://github.com/nulpunkt/yesql-php#mapping-data-on-the-way-in
Ah, found it. It's just a different section. Yeah, awesome!
We have several queries we want to refactor but right now it's scary because of strict order of the parameters. I would love to add support of the names parameters like this:
Do you like the idea? Would you accept a PR for this?