The issues I recently ran into was using more than one schema. And we had the db name in to boot: theDB.myFirstSchema.someTable theDB.mySecondSchema.anotherTable
You do need to know the table name separately. I traced the problem down to a Reactor lookup to verify if the table existed. In MSSQL it was a stored procedure that needed to be passed the table name only or it would not find the table name. However, when trying to determine if a particular field is Identity, the full schema was needed. The full schema is also needed for any FROM statement. My hack - which I would much rather replace with a more elegant schema attribute - was to treat "theDB.myFirstSchema.someTable" as a dot-delimited list and use only the table name where needed. I believe all this is in reference to http://trac.reactorframework.org/reactor/ticket/42 On 8/30/06, Doug Hughes <[EMAIL PROTECTED]> wrote:
Reactor does need to know what is the table name, etc. Reactor will try to surround the table name, column names and more in the correct identifier for the dbms. So, for example, reactor would generate something like this: SELECT [foo].[fooId] FROM [dbname].[dbowner].[foo] as [foo] WHERE .... So, you could put whatever you want into your table name, but chances are your dbms would bork on it. Consider if you tried to set the schema before the foo table: <object name="myschema.foo" /> SELECT [myschema.foo].[fooId] FROM [dbname].[dbowner].[myschema.foo] as [myschema.foo] WHERE .... This won't work. Furthermore, reactor shouldn't try to recognize that the period could mean something. This could have meanings in some dbms and not in others. Right now, Reactor tries to introspect the schma automatically. The problem is that sometimes more than one schema can have a table with the same name. In that case Reactor may not guess correctly. To resolve this we need to allow the user to explicitly specify the correct schema in the object config. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Chiverton Sent: Wednesday, August 30, 2006 9:24 AM To: [email protected] Subject: Re: [Reactor for CF] adding schema names On Wednesday 30 August 2006 13:56, Dan Wilson wrote: > Of course, the use cases vary.... I *think* the case is that most of the tables live in the configured schema, but the odd one or two are exposed from another schema. So you might select foo from bar; and select baz from boo; but also select sillyThing from gash.table; sometimes. The point about bonkers table names is right though - iirc Oracle lets you say something like select bonkers from [EMAIL PROTECTED]; which is why I suggested just letting anything in the name field and this just gets stuffed into the from clause as is. I don't actually know if Reactor needs to be able to figure out which part is the table or not except for file/object names, and we could just force the use of alias in those cases. I would prefer schema over owner, because the schema a table is in is different to the owner of the table. -- Tom Chiverton Helping to synergistically network advanced mindshares **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Matt Williams "It's the question that drives us." -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
