Re: [Glorp-development] OneToManyMapping and OneToOneMapping

[Alan K. <kn...@ac...>]

Sorry, I've been away and didn't manage to get back to this.

Yes, I can now reproduce the problem, and it's a nasty one. It's related to 
the newly introduced partial writes. So, when we commit a unit of work we 
now don't write rows that existed before. However, those rows (such as the 
customer in this case) might be related to other rows that do need writing. 
In this case we can end up creating constraints to the customer row, which 
then makes it appear in the rowmap, and so get written, creating a phantom row.

I believe I've been able to fix this by changing 
UnitOfWork>>createMementoRowMapForObjects not to include new objects, and 
by changing createRowsForPartialWrites to create the new objects rows 
before removing the rows for existing objects. I think this works now. See 
the attached fileout (I hope that captures all the changes).

At 11:03 AM 10/7/2002 -0300, Damian Balliro wrote:
>Thanks for answer my question. I did try your example with the same glorp 
>version but it doesn't work. Make a little change to see what happens.
>
>
>ReadingTest>>testReadCustomerAndAddTransaction
>         | query  customer accountIds newCustomer |
>
>         [session beginTransaction.
>         session beginUnitOfWork.
>         accountIds := self writeCustomer1Rows.
>         query := ReadQuery returningOneOf: Customer
>                                 where: [:person | person id = 27].
>         customer := session execute: query.
>         customer addTransaction: BankTransaction example1.
>         session commitUnitOfWork.
>         newCustomer := session execute: query.
>         self assert: customer == newCustomer.
>         self assert: customer transactions first owner == customer.
>         ]
>                         ensure: [session commitTransaction. self halt.].
>
>
>At the halt time check the database tables and you will see the result. In 
>the Transaction tables you have one row and it is supposed to reference to 
>the Customer id 27, but it references to a new Customer , the one has been 
>added to the Customer table. Its crazy, but it happens. I try it in 3 
>different machines using Access and MYSql (I did my own stuff).
>
>
>
>
>
>What exactly is the case you're trying to run.  If I do the following it 
>works for me in 0.2.12
>
>ReadingTest>>testReadCustomerAndAddTransaction
>         | query  customer accountIds newCustomer |
>
>         [session beginTransaction.
>         session beginUnitOfWork.
>         accountIds := self writeCustomer1Rows.
>         query := ReadQuery returningOneOf: Customer
>                                 where: [:person | person id = 27].
>         customer := session execute: query.
>         customer addTransaction: BankTransaction example1.
>         session commitUnitOfWork.
>         newCustomer := session execute: query.
>         self assert: customer == newCustomer.
>         self assert: customer transactions first owner == customer.
>         ]
>                         ensure: [session rollbackTransaction].
>
>
>although I note that I had to add the following to stop it from crashing 
>due to an unrelated issue that seems like something to do with incremental 
>writes, which needs some further investigation.
>UnitOfWork>>updateSessionCacheFor: anObject withRow: aRow
>         | key existingObject |
>         anObject class == RowMapKey ifTrue: [^self].  "Not cachable"
>         key := aRow primaryKey.
>         existingObject := session cacheLookupForClass: anObject class 
> key: key.
>         existingObject isNil ifTrue: [self addObject: anObject 
> toCacheKeyedBy: key]
>
>Published as 0.2.13 (note: 3 tests still expected to fail. sorry).
>
>At 10:04 AM 10/3/2002 -0300, Damian Balliro wrote:
>
>>Trying to run the Custumer and BankTransaction case, when the Custumer 
>>exists on the database and it is bring from it , when I add a transaction 
>>at the commit time a new Customer is created on the table and the 
>>transaction is mapped to the new Customer not to the read one. Can 
>>somebody help me with that?
>>
>>
>>_________________________________________________________________
>>MSN Photos is the easiest way to share and print your photos: 
>>http://photos.msn.com/support/worldwide.aspx
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Glorp-development mailing list
>>Glo...@li...
>>https://lists.sourceforge.net/lists/listinfo/glorp-development
>
>--
>Alan Knight [|], Cincom Smalltalk Development
>kn...@ac...
>ak...@ci...
>http://www.cincom.com/smalltalk
>
>"I think we've shown simplicity to the world ... but I don't think we've 
>jammed simplicity down the throat of the world to the extent that we 
>really should have" - Ron Jeffries
>
>
>
>
>_________________________________________________________________
>MSN Photos is the easiest way to share and print your photos: 
>http://photos.msn.com/support/worldwide.aspx

--
Alan Knight [|], Cincom Smalltalk Development
kn...@ac...
ak...@ci...
http://www.cincom.com/smalltalk

"I think we've shown simplicity to the world ... but I don't think we've 
jammed simplicity down the throat of the world to the extent that we really 
should have" - Ron Jeffries