Well, surprise, it already works this way. I could have sworn I tried it and it didn't work, but it does. Regular comma-separated names work fine. Wildcards are optional but can be used it desired.
So I guess this is more of an issue with the docs - the page here<https://cayenne.apache.org/docs/3.0/cgen.html>doesn't say comma-separated values are allowed or wildcards, but rather regular expressions. This section is blank in the new docs, so whenever it gets filled in it should be clarified and should include and example with a comma separated list. I suppose I should make a JIRA issue. Thanks, John On Mon, Mar 18, 2013 at 1:40 PM, Andrus Adamchik <[email protected]>wrote: > I tend to agree. I also find regexp confusing in this situation. Yeah, > let's deprecate it and replace with a differently named "include" and > "exclude" properties. Maybe still allow a "*" to be used to match more than > one entity? > > Andrus > > On Mar 14, 2013, at 7:49 PM, John Huss <[email protected]> wrote: > > I've been using CGen for a bit and one confusing aspect of it to me was > the > > way you specific which entities to include for generation. I expected a > > simple comma-separated list, but it requires a regular expression. You > can > > sort of make it work like a comma-separated list by using something like > > this: > > > > includeEntities="Customer|Invoice" > > > > The problem is that if you have entites whose names contain these > > substrings, they will also be included - so an entity named InvoiceDetail > > will also be generated. You can avoid it by using this: > > > > includeEntities="Customer|^Invoice$" > > > > While the vertical bar instead of a comma is unintuitive, but passable, > > requiring this syntax is not friendly. > > > > So my questions are: > > > > 1) Are people actually using the reg-ex here for useful, more complex > > things? > > 2) Would it be reasonable to add another mutually-exclusive property that > > just takes a comma-separated list of entity names? > > > > John > >
