cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: CGen includeEntities attribute
Date Mon, 18 Mar 2013 21:15:14 GMT
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 <andrus@objectstyle.org>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 <johnthuss@gmail.com> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message