Hi Friso,
Never too late for interesting ideas! :)
And yours is interesting. There's the possibility of suffixing the execute
method with the established terms "One" (cardinality 0:1) or with the new
term "Single" (added in jOOQ 3.10, cardinality 1:1). These terms are there
on the fetch API, because they indicate whether the result is a collection
(0:N with fetch() : Result<Record>) or a single record (0:1 with fetchOne :
Record), i.e. a separate method is required to provide a variation on the
resulting type.
I personally think the cardinality of an update operation is not
interesting enough to account for several methods like these. Perhaps we
could allow for passing in a Predicate<Integer> or even a Consumer<Integer>
style type, along the lines of the existing fetchInto(RecordHandler<R>)
method. With that, you could write:
// Reusable consumer:
public static final Consumer<Integer> SINGLE_UPDATE = i ->
Preconditions.checkState(i == 1);
// And then:
DSL.using(config).transaction(t -> {
using(t).insertInto(t).values(...).executeInto(SINGLE_UPDATE);
});
I think that would be the solution that is most consistent with existing
API.
I'll let this settle a bit. I like the idea, but there still needs to be a
bit of refinement on how to exactly implement this API wise.
Lukas
2017-07-28 21:38 GMT+02:00 <[email protected]>:
>
> Hi,
>
> Sorry for the late reply, I find myself doing something like this
> regularly:
>
> DSL.using(config).transaction(t -> {
> int inserted = DSL.using(t).insertInto(t).execute();
> Preconditions.checkState(inserted == 1);
> });
>
> So I guess I could do with a insertSingle (insertChecked?); a method that
> throws an exception if the insert did not insert 1 row (or an update did
> not update one row, or an update that did not at least update one row or a
> delete ...)
>
> Groeten,
>
> Friso
>
> Op woensdag 6 juli 2016 14:16:44 UTC+2 schreef Lukas Eder:
>>
>> Dear group,
>>
>> Part of jOOQ's success is its incredible amount of convenience methods
>> that help reduce the boiler plate code at your side. We do this with
>> massive overloading of API, for instance, when you work with fetch(), you
>> may have noticed how many different types of fetch() there are in jOOQ.
>> ...
>>
>> What's your biggest "itch" in the jOOQ API, which jOOQ could "scratch",
>> or rather, make go away by adding new convenience API?
>>
>> All ideas welcome!
>> Lukas
>>
> --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
