Hi Greg, Thanks for the "Torque design principal review", but to clarify it wasn't the NVARCHAR aspect that I was worried about as we already do our own conversion from specifying VARCHAR and outputting NVARCHAR, it was the "max" size aspect of it that I was inquiring about.
Sorry to say but I've wasted everyone's time with this. The answer is that, apparently, whatever you specify in the size parameter just blindly gets transferred to the resultant sql. If I specify: <column name="windowsDomain" size="max" type="VARCHAR"/> It results correctly with: ,windowsDomain NVARCHAR (max) NULL So if I also specify: <column name="keylist" size="gobbledegook" type="VARCHAR"/> It will result in: ,keylist NVARCHAR (gobbledegook) NULL Good to know for future reference. John -----Original Message----- From: Greg Monroe [mailto:[EMAIL PROTECTED] Sent: November 14, 2008 1:14 PM To: 'Apache Torque Users List' Subject: RE: SQL Server 2005 - varchar(max) First, just a general Torque design principal review... Torque tries to let you create code that is independent of the type of SQL server you are using (while remaining flexible enough to let you access specific server features. When it comes to things like basic column type support, we follow the SQL standards as to what Torque supports. So, if the standard defines an NVARCHAR column type, then we will try to support it across all servers we support. That said, there are actually two parts to this request, using these type of columns in the runtime and generating the SQL statements to create the tables. In the runtime area, I'm pretty sure we already support these columns. If your schema XML says VARCHAR, then the Torque code is using String at the storage type with is Unicode compliant. Torque and Village ultimate set and store these fields via JDBC calls, like getString(column), and the like. The JDBC driver should handle the conversion of the information returned by the SQL server to the correct Java value. So, an NVARCHAR column with Unicode will be mapped directly to a Unicode String with no problems. As to generating SQL with NVarchar column, as I said above, if this is part of the standard, we'll add a column type to the schema. However, if you have a need to do this, it's not hard to create your own generator Platform implementation that uses NVARCHAR when you specify VARCHAR in the XML. Hope makes sense. If not feel free to ask for clarification. > -----Original Message----- > From: jbowman [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2008 10:28 AM > To: torque-user@db.apache.org > Subject: SQL Server 2005 - varchar(max) > > Hi All, > > I'm new to the list so please bear with me if this question has been > previously discussed. > > Is there any version of Torque that supports any of the "new" SQL > Server > 2005 column specification changes, specifically: > > NVARCHAR(max)? > > > The MSDN documentation defines it as: > > "Variable-length Unicode character data. n can be a value from 1 > through 4,000. max indicates that the maximum storage size is 2^31-1 > bytes. The storage size, in bytes, is two times the number of > characters entered + 2 bytes. The data entered can be 0 characters in length." > > If not, are there any plans in the works to support such SQL Server > 2005 changes? > > John > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
