Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <BBA39211-9C1F-4C16-AAFA-0022E681880D@roxanemy.com>
From: Robert Zeigler <robert.zeigler@roxanemy.com>
To: user@cayenne.apache.org
In-Reply-To: <o2q5adb61291004201409s533e76a7q2cee1a4d333209b0@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Elementary Question
Date: Tue, 20 Apr 2010 23:27:58 -0500
References: <7E84A71E-65D3-4D81-B35D-0E31A5BCA3A9@earthlink.net>
  <m2n5adb61291004200625y70f69b6fsce63844720c22008@mail.gmail.com>
  <E85C0B0A-C9F0-4026-9AEF-E7F4D520292A@earthlink.net>
 <p2g5adb61291004200817mc882d310r3b976eb20b5faa83@mail.gmail.com>
  <5D5BB4C3-3E1B-45F6-A8B2-8392443FC377@earthlink.net>
 <n2v5adb61291004200943la4ba362dz1b3a42ae716ae162@mail.gmail.com>
  <B02DCAE8-60E0-44AA-8C38-18254DB19E6E@earthlink.net>
 <y2r5adb61291004201343xfb9a9946idf551adf13021211@mail.gmail.com>
  <BB6A27B5-2E23-4350-99EE-44866A8B3214@roxanemy.com>
 <o2q5adb61291004201409s533e76a7q2cee1a4d333209b0@mail.gmail.com>

Sure... I can understand that.
But if you're generating against a db that supports db-generated keys,  
and you have an entity that requests db-generated keys, then it seems  
like there's no reason to include the row for that entity in the  
auto_pk_support table, other than the fact that having it there  
doesn't do any harm (except confuse new users :), but keeps the  
codebase for the schema generation a little cleaner.  It smells like  
an oversight, but I'm not sure that it is, so I was curious. :)

Robert

On Apr 20, 2010, at 4/204:09 PM , Michael Gentry wrote:

> "I'm actually curious to know the rationale behind that one, myself."
>
> In the beginning ... OK, I'm speculating here because I wasn't around
> in the beginning ... I believe Cayenne ONLY supported the
> AUTO_PK_SUPPORT, although maybe Oracle sequences were there early on.
> Over time, DB-generated key support was added (sometime in 2.x, I
> think) and also PostgreSQL sequences.  It is also the only method that
> is going to work on all DBs.
>
> mrg
>
>
> On Tue, Apr 20, 2010 at 5:01 PM, Robert Zeigler
> <robert.zeigler@roxanemy.com> wrote:
>> I can understand Joe's confusion: not only does cayenne generate the
>> AUTO_PK_SUPPORT table, but it also inserts a row for each table,  
>> regardless
>> of whether that table is using cayenne vs. db-generated ids.
>> I'm actually curious to know the rationale behind that one,  
>> myself. :) I
>> mean, I know cayenne will fall back to using cayenne-generated ids  
>> if the db
>> connected to (or corresponding driver) doesn't support auto-pk  
>> generation.
>> But you should be able to detect that at schema generation time,  
>> and you
>> have the mapping in hand to determine which entities will use db- 
>> generated
>> pks... so... at the very least, shouldn't you only insert a row for  
>> those
>> entities which need it?
>>
>> The flip side, though, is that having an unused row in the db will  
>> have
>> virtually no performance impact, and it keeps the generation code  
>> much
>> simpler. *shrug* Just thinking out loud, I guess... I'd love to  
>> hear the
>> original rationale for including all entities in the table,  
>> regardless of
>> what their pk-generation strategy is. :)
>>
>> Robert
>>
>> On Apr 20, 2010, at 4/203:43 PM , Michael Gentry wrote:
>>
>>> Hi Joe,
>>>
>>> On Tue, Apr 20, 2010 at 1:12 PM, Joe Baldwin <jfbaldwin@earthlink.net 
>>> >
>>> wrote:
>>>>
>>>> Michael,
>>>>
>>>>> However, I would suggest not doing both strategies on the same  
>>>>> table as
>>>>> it will probably bite you in the long run somehow.
>>>>
>>>> That is not my intention (but I agree with you).  I am verifying  
>>>> all of
>>>> my entities right now.  However, the Cayenne Modeler  
>>>> configuration was not
>>>> clear.  You said that if I set the "PK Generation Strategy" to  
>>>> "Database
>>>> Generated" but then I unintentionally had the "Create Primary Key  
>>>> Support"
>>>> checked in the "Generate DB Schema" Options dialog, then it would  
>>>> create the
>>>> AUTO_PK_SUPPORT table.
>>>>
>>>> It is not clear to me why you have this in two separate config
>>>> parameters.  Base on your explanation (in the previous email),  
>>>> that if you
>>>> select the "PK Generation Strategy" type for the individual  
>>>> entities, then
>>>> the "Create Primary Key Support" option should be automatically  
>>>> configured
>>>> at that time.
>>>>
>>>> Said a different way: why would the Cayenne Modeler create
>>>> Cayenne-Managed Primary Key Support for tables with the "PK  
>>>> Generation
>>>> Strategy" to "Database Generated"?
>>>
>>>
>>> I think you are confusing Cayenne Modeler's schema generation  
>>> feature
>>> with Cayenne's runtime primary key support feature.  More below.
>>>
>>>
>>>> I may be wrong, but base on what you had described, it seems like  
>>>> Cayenne
>>>> Modeler is creating a conflicting configuration in this scenario.
>>>
>>>
>>> There is no conflict.  Perhaps if you don't use "Database Generated"
>>> on any DbEntities then it would be safe in Cayenne Modeler to not  
>>> have
>>> the checkbox when generating the SQL to create the AUTO_PK_SUPPORT
>>> table, but I'm not even sure I agree with that idea.  Keep in mind
>>> that each table can have different PK generation options (even  
>>> though
>>> it would potentially be confusing).  Cayenne doesn't stop you from
>>> using the AUTO_PK_SUPPORT on some entities even when you are using
>>> MySQL's auto-generated PK on other entities (for example, you may  
>>> need
>>> higher performance on some tables for bulk inserts).  Cayenne will  
>>> use
>>> whichever strategy you specify for the entity, but allows you to
>>> create the AUTO_PK_SUPPORT if it is needed (your call) when you
>>> generate the SQL.
>>>
>>>
>>>>> If you have Cayenne generating the keys, it'll push them to MySQL.
>>>>
>>>> I agree, but I have clearly set "PK Generation Strategy" to  
>>>> "Database
>>>> Generated".  So my question remains: given that the CM allows  
>>>> conflicting
>>>> parameters, which one takes precedence here?  I have set "PK  
>>>> Generation
>>>> Strategy" to "Database Generated", are you saying that Cayenne  
>>>> then ignores
>>>> this configuration?
>>>>
>>>>
>>>>> However, I would suggest not doing both strategies on the same  
>>>>> table as
>>>>> it will probably bite you in the long run somehow.
>>>>
>>>>
>>>> I agree.  That is *definitely* not my intention, (But as I  
>>>> described
>>>> above, it appears that this is very easy to do with  
>>>> CayenneModeler.)
>>>>
>>>> Michael, what you have described concerning CM is not intuitive.   
>>>> I could
>>>> easily see a designer configuring one table with Cayenne-Managed
>>>> auto-generation, and another with database-auto-generation  
>>>> (because Cayenne
>>>> Modeler allows it).  If what you are saying is true, then  
>>>> selecting the
>>>> "Create Primary Key Support" checkbox, will override they
>>>> "database-auto-generation" parameter.
>>>
>>>
>>> That's actually not at all what I am saying.  Selecting the "Create
>>> Primary Key Support" checkbox in Cayenne Modeler's schema generation
>>> tool just creates it in the schema.  It doesn't override what you  
>>> set
>>> for each individual entity.  Whomever is doing the design needs to
>>> decide how the PKs are generated on each table.  In a lot of
>>> applications it is the same method for all entities, but it doesn't
>>> have to be that way.
>>>
>>>
>>>> If this is as bad as you suggest, then Cayenne Modeler should  
>>>> either
>>>> prevent this from happening or display an explicit warning.
>>>
>>>
>>> I don't think it is bad at all and never suggested it was.  It is a
>>> very important and useful feature.
>>>
>>> mrg
>>
>>