Hi Thomas, 2017-03-06 12:09 GMT+01:00 Thomas GILLET <[email protected]>:
> Hello again, > > >> No, indeed. RecordType is a type descriptor, not an actual value / tuple. >> Here's the distinction: >> >> - Row: an actual QueryPart that can generate a row constructor in SQL. It >> can contain column references as well as values >> - RecordType: A type descriptor for records and rows >> - Record: A map of column references / values pairs >> > > Thanks, that's what I thought. And that's what struck me as a lack of > symmetry (RecordType being Record keys, what should hold Record values?), > hence that "RecordValue" idea. And I didn't see Row as a good candidate > because it's not Record-parameterized. > > But then this RecordType/Row duality make me realize there are two > different use cases here: > - use jOOQ to generate SQL > - use jOOQ-generated objects as a database model > > So maybe that's another reason I tend to like RecordType more than Row: > it's not part of the DSL, so it belongs to the second use-case (which is > clearly the one I'm working with here). Also the 22-arity seems quite > linked to the SQL generation... > Any thought about this distinction? > Indeed, there is some historic irregularity in these API types. 22-arity is indeed linked mostly to the SQL generation, although early jOOQ 3.x releases also snuck it into the rest of the type system. Perhaps that was a mistake. The interesting thing with an API like jOOQ's is that it is almost not possible to design it correctly up front. It grew exploratorily, and each major release cleans up quite a few things. E.g. 4.0 will clean up the distinction between: - Model API (mutable, JavaBeans style) - DSL API (immutable, SQL style) Currently, the two API types are often confused, especially with the DSL API being mutable. At the same time, I'm not 100% convinced that the RecordType type is really so useful on its own. I'm still hoping that a more reusable row type type will cristallise (within the constraints of the limited Java possibilities - don't we all wish for higher kinded types?), but that has not been discovered yet. > > >> Now, before we proceed, I'd really love to have some more concrete >> examples of use-cases where constraint meta data needs to be queried in >> client code. I know you're trying to implement that tree persistence on top >> of jOOQ (see other discussion), but let's not go to the bigger picture, >> let's focus on concrete operations that you're trying to do and where the >> lack of type information is bothering you. Do you have some minimal >> examples you could share? >> > > With an hypothetical Key<R, K> type: [...] > Thanks for the explanations. That's very useful. Perhaps there's an improvement in there for a future jOOQ version. I'll revisit this discussion when I run again into passing around keys. This also happens internally in UpdatableRecord, although the pain simply hasn't been big enough yet to factor out common logic here into the public API. Best Regards, 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.
