On Mie, 12 de Enero de 2005, 19:05, Armin Waibel dijo: > Have a look at PersistenceBrokerImpl line 1527. > > I attached a fix that should work (not tested). > > The main problem was Identity class. This class obtain new id's and set > the PK values in the persistent object (if PK fields are null). In my > opinion this should not happen (bad design), but to change this will be > costly.
I reviewed the code. You are totally right! The problem is in the design. :-( The suggested solution have a small problem too: In fact is posible to have a PK=null. And this should not be a problem. AFAIK, the condition that each PK must meet (in some DBs ie: PostgreSQL) is that it must be UNIQUE. It does not matter if PK= null because, in theory is posible to have 1 row with PK=null and this should be OK since it is the only one that use null as PK. While I understand almost nobody use a PK=null, I think we cannot restrict the use of this "DB feature". Now think what if a PK is composed of more than 1 fields. Here again, one of them can be null and this does not broke the DB, but the patch will fail. As you told, the problem is in the Identity design. I see 2 posible solutions: A-Specialize a new Identity Object for QueryByIdentity that will not try to fill primary keys. B-Add new methods in the current Identity to be used by QueryByIdentity that will not try to retrieve new values for PK's. WDYT? Best Regards, Antonio Gallardo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
