cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: CGen includeEntities attribute
Date Tue, 19 Mar 2013 16:13:35 GMT
Ah ok. I guess we just need to add "This is an Ant counterpart of "xyz" goal of maven-cayenne-plugin
described above." to each Ant task.

Andrus

On Mar 19, 2013, at 6:48 PM, John Huss <johnthuss@gmail.com> wrote:

> Well, I use Ant and that section isn't filled in.  :-P
> 
> I think it would be better to not mention regular expressions and just to
> say something like:
> 
> A comma-separated list of ObjEntity names to exclude from template
> generation. Wildcards may be used to match multiple entities, for example,
> 'Artist*'.
> 
> 
> 
> On Tue, Mar 19, 2013 at 1:35 AM, Andrus Adamchik <andrus@objectstyle.org>wrote:
> 
>> I should've checked before answering :) Actually looking at 3.1 docs, it
>> seems to be there, and very explicit:
>> 
>> 
>> https://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#maven-projects
>> 
>> "excludeEntities        A comma-separated list of ObjEntity patterns
>> (expressed as a perl5 regex) to exclude from template generation. By
>> default none of the DataMap entities are excluded."
>> 
>> "includeEntities        A comma-separated list of ObjEntity patterns
>> (expressed as a perl5 regex) to include from template generation. By
>> default all DataMap entities are included."
>> 
>> So where is it missing?
>> 
>> (and we can update 3.0 docs as well)
>> 
>> Andrus
>> 
>> On Mar 19, 2013, at 12:15 AM, John Huss <johnthuss@gmail.com> wrote:
>> 
>>> 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
View raw message