Hi, Thanks for your reply.
A few things struck me as I read about the adapter. It says I have to write an method that returns whether ' or " is being used. I'm thinking that this method should return the standard, which is ' and if you want another behaviour you should implement that method. Which brings me to a larger point. Shouldn't there be a standard Adapter? So that any database that fulfills that level of the standard will work. I'm thinking of for instance Oracle and Mimer. If you had a SQL-92 Entry adapter it should work on both. A core SQL-99 adapter would likely work on both. Torque is created because the database vendors have SQL dialects. But shouldn't torque at least promote using the standard? Another question, if a database supports a standard way of doing something and a non standard way. Does torque just use 'one of them' or do you actively pursue the standard? Regards, Olof Edlund -----Ursprungligt meddelande----- Fr�n: John McNally [mailto:[EMAIL PROTECTED]] Skickat: den 30 juli 2002 18:43 Till: Turbine Torque Developers List �mne: Re: Thinking about writing a DB Adapter, but what is this withtable locking? On Tue, 2002-07-30 at 09:40, John McNally wrote: > Torque does use the adapter code internally. Sorry, that was suppost to Torque does NOT use ... So if you do not call the > methods in your code, it will not matter. An implementation that throws > UnsupportedOperationExceptions would be acceptable. Fulcrum's security > service makes use of this code, iirc. So if you don't implement it, you > will probably not be able to use that. > > john mcnally > > On Tue, 2002-07-30 at 07:07, Olof Edlund wrote: > > Hi, > > > > I'm thinking about writing a DB adapter for Mimer SQL Engine ( www.mimer.com > > <http://www.mimer.com/> ). I read the methods that needs to be implemented > > and I saw that I need to implement void lockTable(Connection con, String > > table) if the database doesn't support table locking. > > > > Now, heres the funny part. Mimer doesn't use locking at all. It uses > > something called optimistic concurrency control (pessimistic concurrency > > control is locking). But this is done at the row level. You can read more > > about optimistic concurrency control here: > > http://developer.mimer.com/features/feature_15.htm > > > > 1) Does anyone know if that will work with Torque? > > 2) Do I only need to implement the table locking at the process level > > or do I need to prevent several processes from writing to the same table at > > once? > > 3) And here's the trickiest question: what happens if I don't > > implement table locking at all in an occ database? Will it somehow magically > > work? > > > > And finally, why does the design rely on table locking and how does that > > affect performance? > > > > Regards, > > > > Olof Edlund > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
