It tells the Cayenne Runtime where to find/generate the value for the PK.
Normally, they're generated by some "strategy" specified in the model,
or sometimes they are explicitly assigned by the application.
However, a dependent primary key (like a join table) has its primary
key value set with the value of the master primary key.
Ie,
a User/Account join table composed of USER_ID and ACCOUNT_ID, both
primary keys, needs to get the value for each from the primary key of
the USER table and the ACCOUNT table. We don't want to generate one.
We don't want to assign one. We want it to pick up the existing
value and reuse it.
Hope this helps explain dependent primary keys better.
On 5/12/08, Scott Anderson <sanderso..irvana.com> wrote:
> Seems like a pointless annotation; vaguely equivalent to the reverse of the relationship being ON DELETE CASCADE.
>
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienen..mail.com]
>
> Sent: Mon 5/12/2008 7:16 PM
> To: use..ayenne.apache.org
> Subject: Re: one-to-many problem
>
> Yeah, in retrospect it won't work because command.name isn't a pk.
>
> http://cayenne.apache.org/doc12/to-dep-pk-checkbox.html should explain
> it fairly well.
>
> On 5/12/08, Scott Anderson <sanderso..irvana.com> wrote:
> > Can't check the box. Can you explain what that does? I read the
> > documentation for it about 100 times and I still can't make heads or
> > tails of it.
> >
> >
> > -----Original Message-----
> > From: Mike Kienenberger [mailto:mkienen..mail.com]
> > Sent: Monday, May 12, 2008 6:57 PM
> > To: use..ayenne.apache.org
> > Subject: Re: one-to-many problem
> >
> > One thing you could try is to make command.name -> command_alias.name
> > to-dependent-key=true if it's not already set that way. Don't know if
> > it'll help, though.
> >
> >
> > On 5/12/08, Scott Anderson <sanderso..irvana.com> wrote:
> > > I've got a table `command which has:
> > > `id` int PK
> > > `name` varchar(32) UNIQUE
> > >
> > > and a table `command_alias` which has
> > > `alias` varchar(32) PK
> > > `name` varchar(32) FK REF `command`.`name`
> > >
> > > Take special note how `command_alias`.`name` is a FK to
> > `command`.`name`
> > > (unique field) and not `command`.`id` (the PK)
> > >
> > > The following code chokes:
> > > public static CommandAlias create(Command command, String
> > alias)
> > > {
> > > CommandAlias ca =
> > > DatabaseContext.getContext().newObject(CommandAlias.class);
> > > ca.setAlias(alias);
> > > ca.setToCommand(command);
> > > command.addToAliases(ca);
> > > try {
> > > ca.updateRow();
> > > return ca;
> > > } catch(Exception e) {
> > > Out.exception(e);
> > > return null;
> > > }
> > > }
> > >
> > > With the error:
> > >
> > > May 12, 2008 6:15:55 PM org.apache.cayenne.access.QueryLogger
> > logQuery
> > > INFO: INSERT INTO command_alias (alias, name) VALUES (?, ?)
> > > INFO: [batch bind: 1->alias:'aa', 2->name:NULL]
> > > May 12, 2008 6:15:55 PM org.apache.cayenne.access.QueryLogger
> > > logQueryError
> > > INFO: *** error.
> > > java.sql.SQLIntegrityConstraintViolationException: Column 'NAME'
> > cannot
> > > accept a NULL value.
> > >
> > >
> > > I am 100% sure that I am not sending a null Command object. I believe
> > > this stems from the fact that the relationship is not a FK-PK
> > > relationship, but a FK-UNIQUE relationship, as evidenced by the fact
> > > that if I make the `command_alias`.`name` field visible in the code,
> > and
> > > set do ca.setName(command.getName()) then this error does not occur.
> > >
> > > I am using a 3.0 snapshot from March.
> > >
> > >
> > > And here's the relevant sections of my mapping file (I removed some
> > > unrelated fields from command):
> > >
> > > <db-entity name="command">
> > > <db-attribute name="id" type="INTEGER"
> > > isPrimaryKey="true" isGenerated="true" isMandatory="true"
> > length="11"/>
> > > <db-attribute name="name" type="VARCHAR"
> > > isMandatory="true" length="32"/>
> > > </db-entity>
> > > <db-entity name="command_alias">
> > > <db-attribute name="alias" type="VARCHAR"
> > > isPrimaryKey="true" isMandatory="true" length="32"/>
> > > <db-attribute name="name" type="VARCHAR" length="32"/>
> > > </db-entity>
> > > <obj-entity name="Command" className="net.bnubot.db.Command"
> > > dbEntityName="command"
> > superClassName="net.bnubot.db.CustomDataObject">
> > > <obj-attribute name="name" type="java.lang.String"
> > > db-attribute-path="name"/>
> > > </obj-entity>
> > > <obj-entity name="CommandAlias"
> > > className="net.bnubot.db.CommandAlias" dbEntityName="command_alias"
> > > superClassName="net.bnubot.db.CustomDataObject">
> > > <obj-attribute name="alias" type="java.lang.String"
> > > db-attribute-path="alias"/>
> > > </obj-entity>
> > > <db-relationship name="commandAliasArray" source="command"
> > > target="command_alias" toMany="true">
> > > <db-attribute-pair source="name" target="name"/>
> > > </db-relationship>
> > > <db-relationship name="toCommand" source="command_alias"
> > > target="command" toMany="false">
> > > <db-attribute-pair source="name" target="name"/>
> > > </db-relationship>
> > > <obj-relationship name="aliases" source="Command"
> > > target="CommandAlias" deleteRule="Deny"
> > > db-relationship-path="commandAliasArray"/>
> > > <obj-relationship name="toCommand" source="CommandAlias"
> > > target="Command" db-relationship-path="toCommand"/>
> > >
> >
>
>
This archive was generated by hypermail 2.0.0 : Tue May 13 2008 - 13:03:58 EDT