beExclusive and INSERT with double relationships

Well, it does sound like you have a circularity there. From the
description, you have an address holding a reference to the customer
key, and a customer holding a reference to an address key. So if you
have a new customer and a new address, there's potentially no order in
which they can be inserted. Normally what Glorp will do is sort
according to the foreign key constraints, but in that case there's a
circularity, so it would just pick an order.

If the customer's primary key isn't generated, then you might be able to
do remove the foreign key constraint in the table description for
addresses and see if that helps.

I'm not sure what's going on with the addresses list not getting the
value set. You might try looking at the SQL that's being generated. The
order might tell you something. Or you can set debugWrite on the mapping
and see what's happening when it goes to write it.

jtuchel wrote:

> Hi there, it's me again ;-)
>
> I found a new problem with an old version of GLORP ;-)
>
> Here's what my model looks like. I have a class named customer which
> holds a collection of Addresses in an exclusive 1:n relationship. In
> addition to that it also has a 1:1 relationship to the same
> class/table which holds the key of the Address that is the primary
> contact address of the Customer.
>
> In such a setting, GLORP cannot resolve the correct order to insert.
> If I create a Customer with 1 address, without setting the
> primaryAddress variable (which is okay in my domain), it will always
> insert the address first with the foreign key being NULL (since IDs
> are sequences and the Customer is inserted later).
>
> It doesn't help to register the Customer with the session before
> inserting Addresses.
>
> When I remove the mapping for the 1:1 foreign key in the Customer
> table (primaryAddress), everything works fine.
>
> But wait, it gets even worse:
> If I create a customer and add an address and also set the
> primaryAddress, I'll end up with the primaryAddress containing an
> Address, while the addresses list is empty. The address that is saved
> as primaryAddress has no back pointer to the Customer, although it had
> the Customer instVar set before inserting.
>
> Is there something special I can do in my descriptor to enable holding
> a collection of Addresses as well as one primaryAddress in two
> separate relationships at the same time?
> Is this a bug that is fixed in later GLORP versions or is it just a
> circularity that cannot be resolved on INSERTs? UPDATEing works fine
> once a Customer without any Addresses has been saved. I can add
> addresses and change the primaryAddress and commit without any
> problems in later transactions.
>
> Joachim
> --

If the foreign key isn't there you might need to explicitly specify the join for some relationships, as Glorp may not be able to figure it out automatically. It will know what type of object to interpret it as based on the descriptor. The foreign key constraints in the tables are used for creating tables, for figuring out joins if they're not specified explicitly, and to compute ordering. I think that's all they're used for.

jtuchel wrote:

Alan,

You're right, it's a circular constraints conflict: Addresses have a foreign key for the Customer and a Customer has a foreign key for its primary Address.

Ah, removing one of the foreign key constraints: stupid me - I never thought of that!

I'd rather remove the foreign key constraint of the 1:1 relation for the primaryAddress. But then, how would I make sure an ID gets interpreted as an Address on Read? Is the classModelFor..: sufficient for that if I set a type: for the variable? Removing the foreign key from the :n-part of the list of Addresses sounds a bit strange to me...

So I'll see if I can get anywhere with this.

As always: thanks a lot for helping me think.

Joachim

Am Dienstag, 3. April 2012 15:15:21 UTC+2 schrieb AlanKnight:

Well, it does sound like you have a circularity there. From the
description, you have an address holding a reference to the customer
key, and a customer holding a reference to an address key. So if you
have a new customer and a new address, there's potentially no order in
which they can be inserted. Normally what Glorp will do is sort
according to the foreign key constraints, but in that case there's a
circularity, so it would just pick an order.

If the customer's primary key isn't generated, then you might be able to
do remove the foreign key constraint in the table description for
addresses and see if that helps.

I'm not sure what's going on with the addresses list not getting the
value set. You might try looking at the SQL that's being generated. The
order might tell you something. Or you can set debugWrite on the mapping
and see what's happening when it goes to write it.

jtuchel wrote:

> Hi there, it's me again ;-)
>
> I found a new problem with an old version of GLORP ;-)
>
> Here's what my model looks like. I have a class named customer which
> holds a collection of Addresses in an exclusive 1:n relationship. In
> addition to that it also has a 1:1 relationship to the same
> class/table which holds the key of the Address that is the primary
> contact address of the Customer.
>
> In such a setting, GLORP cannot resolve the correct order to insert.
> If I create a Customer with 1 address, without setting the
> primaryAddress variable (which is okay in my domain), it will always
> insert the address first with the foreign key being NULL (since IDs
> are sequences and the Customer is inserted later).
>
> It doesn't help to register the Customer with the session before
> inserting Addresses.
>
> When I remove the mapping for the 1:1 foreign key in the Customer
> table (primaryAddress), everything works fine.
>
> But wait, it gets even worse:
> If I create a customer and add an address and also set the
> primaryAddress, I'll end up with the primaryAddress containing an
> Address, while the addresses list is empty. The address that is saved
> as primaryAddress has no back pointer to the Customer, although it had
> the Customer instVar set before inserting.
>
> Is there something special I can do in my descriptor to enable holding
> a collection of Addresses as well as one primaryAddress in two
> separate relationships at the same time?
> Is this a bug that is fixed in later GLORP versions or is it just a
> circularity that cannot be resolved on INSERTs? UPDATEing works fine
> once a Customer without any Addresses has been saved. I can add
> addresses and change the primaryAddress and commit without any
> problems in later transactions.
>
> Joachim
> --