Hi David,
2013/6/10 David Fox <[email protected]> > Excellent, thank you! I will see how much I can do with generating the > built in JSR-303 validators. > > I didn't want to get ahead of myself, but had also thought about a SQL > parser for more complex expressions. When I think of how Hibernate does > things, the validators that one might write for a class are in almost all > cases impossible to push into the database schema. This is why hbm2ddl only > utilizes a small number of the annotations in its generation. However, > coming from the database up to Java gives us a lot more flexibility. That's what it looks like, at first. But what would you do with a CHECK constraint like this one: CHECK (a < ANY (SELECT x FROM b)) There are limits to both approaches :-) > Here's another use case that I feel is common and could be handled: > > start_date date NOT NULL, > end_date date NOT NULL, > CHECK (start_date <= end_date) > > This could be quite easily done by generating a custom validator. I need > to think a little more about it, but I feel this would be an amazing > feature. You'd have a true source of your data constraints exposed in a way > which is useful in the application layer and the user interface. > Yes, lots of useful things could be derived from such a parser. However, I think that jOOQ shouldn't go too far with implementations. I'm more thinking about exposing a code generation SPI where annotation code can be injected in jOOQ-generated code. Think about injecting JAXB annotations, for instance... Cheers Lukas > Cheers, > Dave > > On Sunday, June 9, 2013 8:27:08 AM UTC-4, Lukas Eder wrote: >> >> >> >> >> 2013/6/9 Lukas Eder <[email protected]> >> >> Hi Dave, >>> >>> CHECK constraints are currently not exposed by jOOQ-meta, and thus not >>> leveraged by the code generator. I had previously thought about mapping >>> CHECK (COL IN ('A', 'B', 'C')) constraints to generated Java enums. Getting >>> this right and reliable would probably involve creating an actual SQL >>> parser to evaluate the CHECK constraint. >>> >>> Your use-case is another good one, where these things might be >>> leveraged. I have created a feature request to expose CHECK constraints in >>> jOOQ-meta: >>> https://github.com/jOOQ/jOOQ/**issues/2509<https://github.com/jOOQ/jOOQ/issues/2509> >>> >> >> #2509 has been implemented on GitHub master and will be added in jOOQ 3.1: >> https://github.com/jOOQ/jOOQ/**commit/**297a6ae98c2808c54b58576adbf6a5** >> 0c7ee26ef0<https://github.com/jOOQ/jOOQ/commit/297a6ae98c2808c54b58576adbf6a50c7ee26ef0> >> >> I have released a 3.1.0-SNAPSHOT version, early feedback is very welcome! >> https://oss.sonatype.org/**content/repositories/**snapshots/org/jooq/<https://oss.sonatype.org/content/repositories/snapshots/org/jooq/> >> >> Cheers >> Lukas >> >> >>> >>> >>> Note that this will not be a column-property. DDL allowing to specify >>> CHECK constraints on single columns is just syntactic sugar as the >>> INFORMATION_SCHEMA only exposes constraints on a schema-level. They can >>> still be mapped to tables by joining CHECK_CONSTRAINTS to >>> TABLE_CONSTRAINTS. More info can be found in the PostgreSQL manual [1] and >>> in the SQL-92 Standard [2]. An example of such a query: >>> >>> *select * >>> tc.table_schema, >>> tc.table_name, >>> cc.check_clause >>> *from * >>> information_schema.table_**constraints tc >>> *join* >>> information_schema.check_**constraints cc >>> *using *(constraint_catalog, constraint_schema, constraint_name); >>> >>> >>> Cheers >>> Lukas >>> >>> [1]: >>> http://www.postgresql.**org/docs/9.2/static/ddl-**constraints.html<http://www.postgresql.org/docs/9.2/static/ddl-constraints.html> >>> [2]: >>> http://www.andrew.cmu.**edu/user/shadow/sql/sql1992.**txt<http://www.andrew.cmu.edu/user/shadow/sql/sql1992.txt> >>> >>> >>> >>> 2013/6/7 David Fox <[email protected]> >>> >>>> I am loving JOOQ! I have a question regarding code generation. I was >>>> trying to write a generator which would add the rest of the JSR-303 >>>> validation annotations based on common patterns in my table definitions. >>>> >>>> For example, in one column (I'm using PostgreSQL): >>>> >>>> name varchar(32) NOT NULL CHECK (name ~* '^[a-zA-Z0-9_]+$'), >>>> >>>> would result in: >>>> >>>> @javax.validation.constraints.**NotNull >>>> @javax.validation.constraints.**Size(max = 32) >>>> @javax.validation.constraints.**Pattern(regex="^[a-zA-Z0-9_]+$**") >>>> public java.lang.String getName() { >>>> return (java.lang.String) getValue(1); >>>> } >>>> >>>> for the property. However, I cannot see how to access the constraints >>>> from the ColumnDefinition. Is it possible to access this information? >>>> >>>> Thanks in Advance, >>>> Dave >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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 jooq-user+...@**googlegroups.com. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>> >>> >> -- > 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/groups/opt_out. > > > -- 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/groups/opt_out.
