db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: [jira] Closed: (TORQUE-69) Record.save() may not work if there is no primary key but no error is thrown.
Date Wed, 17 Oct 2007 19:21:33 GMT
Thomas Vandahl said on Wednesday, October 17, 2007 1:55 PM
> I'm not entirely sure if that is indeed the solution for the 
> problem (even if it has been suggested in the issue). 
> Sometimes one has to cope with existing database designs. In 
> this case, Torque would simply refuse to work - which is 
> least annoying.

IMHO, it's a bit more than annoying.  Especially, since this 
behaviour is not well documented.  It can take a great deal of
time to debug what is happening (especially since Torque 
doesn't log updates/deletes). 

In my particular case, I was creating a Torque based Data Access 
Object implimentation for jForum.  This has a LOT of poor DB 
design (mostly inherited from PhPBB which it was it's conversion 
basis..).  Plus, there was not a lot of testing that could be done 
until the full suite of 20 odd DAO interfaces were implimented. 
So by the time I knew there was a problem, I had to go back and 
manually identify all the places that didn't the work and didn't 
let me know they failed.  NOT FUN.

IMHO, any good object layer (O/R mapper, SoA, TCP, whatever) should 
include a "contract" proviso that if it can't do what you asked it
to, it should tell you and not just swallow exceptions/errors.
> I suspect that any O/R mapper will have problems with tables 
> without primary keys because there is no fixed object/record-relation.
> Nevertheless those table designs exist. How do others handle 
> this case?

OK, off the soap box now... FWIW, I dealt with this problem in three
main ways.  First, a lot of the tables did not have primary keys 
defined, but had "defacto" primary keys.  Generally in the form of
two or three fields that made the record unique. For these, I just
modified the XML schema to use these.  Torque was happy and it made
the SQL structure a little more robust.

In some cases, there was no definitive key fields.  For these, I 
could still use the Torque select and insert methods.  But for the
delete and update needs, I created manual SQL statements using 
Torque's field constants and called BasePeer.executeStatement 
with this.

It's been a while, but I also had a vague memory of using the
doUpdate(criteria, criteria) to fix some stuff as well.
DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message