[Lift] Re: todo app., Oracle: Invalid column type
I'm deploying a new version of 1.0.1-SNAPSHOT right now onto scala-tools.org. It should be ready in 30 minutes or so with the fixes for Oracle and PostgreSQL. Derek On Tue, Aug 11, 2009 at 9:40 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: Yeah, that's basically how you do it in PostgreSQL, although they have an alias SERIAL that does the work of setting up the sequence and everything for you. Derek On Tue, Aug 11, 2009 at 10:23 AM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: ROWID is indeed a pseudo-column that isn't even stable, to my knowledge. I've always know it as a 0-based index over the rows returned from a query. As of 9i, at least, Oracle insisted that you implement auto-incrementing columns manually using a sequence and an associated trigger. I presume that they have a good reason for this, perhaps related to replication or something. It's a hassle. Kris On Mon, Aug 10, 2009 at 4:26 PM, Derek Chen-Beckerdchenbec...@gmail.com wrote: OK, I think that I've at least figured out the cause of the exception. The Oracle driver is set to use ROWID for primary keys and long indices. As far as I can tell from the Oracle docs, ROWID is a pseudo-column and shouldn't really be used as a column type in table creation DDL. The Boolean conversion appears to be working correctly, so now I just need to figure out the best way to abstract auto-increment column creation. Derek On Mon, Aug 10, 2009 at 1:51 AM, Jon Kleiser jon.klei...@usit.uio.no wrote: Hi, Here's the contents of my default.props file: db.driver = oracle.jdbc.OracleDriver db.url = jdbc:oracle:thin:@myserver.site.no:1540:mydatabase db.user = myuser db.password = xxx The file is located in todo/src/main/webapp/WEB-INF/classes/props/ /Jon On 8/10/09 5:01 AM, Derek Chen-Becker wrote: Or at least the JDBC connection URL that you're using (no passwords or username needed). On Sun, Aug 9, 2009 at 8:25 AM, Derek Chen-Becker dchenbec...@gmail.com mailto:dchenbec...@gmail.com wrote: Please send me the props file. I want to duplicate exactly (as much as possible) what you're doing. Derek On Sat, Aug 8, 2009 at 2:14 PM, Jon Kleiser jon.klei...@usit.uio.no mailto:jon.klei...@usit.uio.no wrote: Hi Derek, The attached file should be identical to the project I use for the Oracle testing, except that the file specifying the Oracle connection (was it default.props?) is missing. I have it on my PPC Mac, not here. I guess you know how to create that file and where to put it. If you're not sure, let me know, and I'll send you the info early Monday (or later). /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
ROWID is indeed a pseudo-column that isn't even stable, to my knowledge. I've always know it as a 0-based index over the rows returned from a query. As of 9i, at least, Oracle insisted that you implement auto-incrementing columns manually using a sequence and an associated trigger. I presume that they have a good reason for this, perhaps related to replication or something. It's a hassle. Kris On Mon, Aug 10, 2009 at 4:26 PM, Derek Chen-Beckerdchenbec...@gmail.com wrote: OK, I think that I've at least figured out the cause of the exception. The Oracle driver is set to use ROWID for primary keys and long indices. As far as I can tell from the Oracle docs, ROWID is a pseudo-column and shouldn't really be used as a column type in table creation DDL. The Boolean conversion appears to be working correctly, so now I just need to figure out the best way to abstract auto-increment column creation. Derek On Mon, Aug 10, 2009 at 1:51 AM, Jon Kleiser jon.klei...@usit.uio.no wrote: Hi, Here's the contents of my default.props file: db.driver = oracle.jdbc.OracleDriver db.url = jdbc:oracle:thin:@myserver.site.no:1540:mydatabase db.user = myuser db.password = xxx The file is located in todo/src/main/webapp/WEB-INF/classes/props/ /Jon On 8/10/09 5:01 AM, Derek Chen-Becker wrote: Or at least the JDBC connection URL that you're using (no passwords or username needed). On Sun, Aug 9, 2009 at 8:25 AM, Derek Chen-Becker dchenbec...@gmail.com mailto:dchenbec...@gmail.com wrote: Please send me the props file. I want to duplicate exactly (as much as possible) what you're doing. Derek On Sat, Aug 8, 2009 at 2:14 PM, Jon Kleiser jon.klei...@usit.uio.no mailto:jon.klei...@usit.uio.no wrote: Hi Derek, The attached file should be identical to the project I use for the Oracle testing, except that the file specifying the Oracle connection (was it default.props?) is missing. I have it on my PPC Mac, not here. I guess you know how to create that file and where to put it. If you're not sure, let me know, and I'll send you the info early Monday (or later). /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
Yeah, that's basically how you do it in PostgreSQL, although they have an alias SERIAL that does the work of setting up the sequence and everything for you. Derek On Tue, Aug 11, 2009 at 10:23 AM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: ROWID is indeed a pseudo-column that isn't even stable, to my knowledge. I've always know it as a 0-based index over the rows returned from a query. As of 9i, at least, Oracle insisted that you implement auto-incrementing columns manually using a sequence and an associated trigger. I presume that they have a good reason for this, perhaps related to replication or something. It's a hassle. Kris On Mon, Aug 10, 2009 at 4:26 PM, Derek Chen-Beckerdchenbec...@gmail.com wrote: OK, I think that I've at least figured out the cause of the exception. The Oracle driver is set to use ROWID for primary keys and long indices. As far as I can tell from the Oracle docs, ROWID is a pseudo-column and shouldn't really be used as a column type in table creation DDL. The Boolean conversion appears to be working correctly, so now I just need to figure out the best way to abstract auto-increment column creation. Derek On Mon, Aug 10, 2009 at 1:51 AM, Jon Kleiser jon.klei...@usit.uio.no wrote: Hi, Here's the contents of my default.props file: db.driver = oracle.jdbc.OracleDriver db.url = jdbc:oracle:thin:@myserver.site.no:1540:mydatabase db.user = myuser db.password = xxx The file is located in todo/src/main/webapp/WEB-INF/classes/props/ /Jon On 8/10/09 5:01 AM, Derek Chen-Becker wrote: Or at least the JDBC connection URL that you're using (no passwords or username needed). On Sun, Aug 9, 2009 at 8:25 AM, Derek Chen-Becker dchenbec...@gmail.com mailto:dchenbec...@gmail.com wrote: Please send me the props file. I want to duplicate exactly (as much as possible) what you're doing. Derek On Sat, Aug 8, 2009 at 2:14 PM, Jon Kleiser jon.klei...@usit.uio.no mailto:jon.klei...@usit.uio.no wrote: Hi Derek, The attached file should be identical to the project I use for the Oracle testing, except that the file specifying the Oracle connection (was it default.props?) is missing. I have it on my PPC Mac, not here. I guess you know how to create that file and where to put it. If you're not sure, let me know, and I'll send you the info early Monday (or later). /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
Jon, could you please send me your project so that I can debug locally? I finally got Oracle XE installed after a long battle and I'd like to do some direct tests here. Thanks, Derek On Fri, Aug 7, 2009 at 9:23 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: OK, I'm going to look into this some more. I have no idea where this null is coming from but I'll try to do some more debug on my end. Derek On Fri, Aug 7, 2009 at 7:23 AM, Jon Kleiser jon.klei...@usit.uio.nowrote: Here's the complete text I get in my browser: Exception occured while processing /user_mgt/sign_up Message: java.sql.SQLException: ORA-01400: cannot insert NULL into (FS.USERS.ID) oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745) oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219) oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:970) oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190) oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3370) oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3454) net.liftweb.mapper.MetaMapper$$anonfun$12.prepStat$1(MetaMapper.scala:642) net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$19.apply(MetaMapper.scala:659) net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$19.apply(MetaMapper.scala:659) net.liftweb.mapper.DB$$anonfun$prepareStatement$2.apply(DB.scala:292) net.liftweb.mapper.DB$$anonfun$prepareStatement$2.apply(DB.scala:288) net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241) net.liftweb.util.Helpers$.calcTime(Helpers.scala:29) net.liftweb.mapper.DB$.prepareStatement(DB.scala:288) net.liftweb.mapper.MetaMapper$$anonfun$12.apply(MetaMapper.scala:658) net.liftweb.mapper.MetaMapper$$anonfun$12.apply(MetaMapper.scala:578) net.liftweb.mapper.DB$.use(DB.scala:305) net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:577) com.liftworkshop.model.User$$$M$11e2eb90.save(User.scala:9) com.liftworkshop.model.User$$$A$11e2eb90.save(generated) com.liftworkshop.model.User$.save(generated) net.liftweb.mapper.Mapper$$anonfun$save$1.apply(Mapper.scala:84) net.liftweb.mapper.Mapper$$anonfun$save$1.apply(Mapper.scala:84) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) net.liftweb.mapper.Safe$.runSafe(Safe.scala:44) net.liftweb.mapper.Mapper$class.runSafe(Mapper.scala:50) com.liftworkshop.model.User$$M$23578d51.runSafe(User.scala:24) com.liftworkshop.model.User$$A$23578d51.runSafe(generated) com.liftworkshop.model.User.runSafe(generated) net.liftweb.mapper.Mapper$class.save(Mapper.scala:83) com.liftworkshop.model.User$$M$23578d51.save(User.scala:24) com.liftworkshop.model.User$$A$23578d51.save(generated) com.liftworkshop.model.User.save(generated) net.liftweb.mapper.MetaMegaProtoUser$class.testSignup$1(ProtoUser.scala:343) net.liftweb.mapper.MetaMegaProtoUser$$anonfun$innerSignup$1$1.apply(ProtoUser.scala:360) net.liftweb.mapper.MetaMegaProtoUser$$anonfun$innerSignup$1$1.apply(ProtoUser.scala:360) net.liftweb.http.S$NFuncHolder$$anonfun$apply$46.apply(S.scala:941) net.liftweb.http.S$NFuncHolder$$anonfun$apply$46.apply(S.scala:941) scala.List.map(List.scala:805) net.liftweb.http.S$NFuncHolder.apply(S.scala:941) net.liftweb.http.LiftSession$$anonfun$buildFunc$1$2.apply(LiftSession.scala:307) net.liftweb.http.LiftSession$$anonfun$5$$anonfun$apply$19.apply(LiftSession.scala:322) net.liftweb.http.LiftSession$$anonfun$5$$anonfun$apply$19.apply(LiftSession.scala:322) scala.List.map(List.scala:805) net.liftweb.http.LiftSession$$anonfun$5.apply(LiftSession.scala:322) net.liftweb.http.LiftSession$$anonfun$5.apply(LiftSession.scala:311) scala.List.flatMap(List.scala:1125) net.liftweb.http.LiftSession.runParams(LiftSession.scala:311) net.liftweb.http.LiftSession.processRequest(LiftSession.scala:449) net.liftweb.http.LiftServlet.net $liftweb$http$LiftServlet$$dispatchStatefulRequest(LiftServlet.scala:244) net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala:176) net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala:176) net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:398) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$$anonfun$apply$16.apply(S.scala:453) net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:372) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$doAround$1.apply(S.scala:373)
[Lift] Re: todo app., Oracle: Invalid column type
Hi Derek,
For me this sounds fine, but then I'm still a Lift and Scala newbie. I
think the best way is just to try it. ;-)
Whenever you have something that I can try, let me know.
/Jon
On Jul 23, 10:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
OK, I think that this is happening because when we use the JDBC setObject
call, we explicitly send the type. As far as I can tell the Oracle driver
doesn't like java.sql.Types.BOOLEAN *at all*, so I'm trying to determine the
best way to compensate. I'm not sure how common something like this might
be, so it might be nice to allow the net.liftweb.mapper.Driver class to
provide a partial function that allows the vendor-specific driver to remap
the type. I would add something like:
abstract class DriverType ... {
def columnTypeRemapper : PartialFunction[Int,Int] = {
case x = x
}
}
and then in the Oracle Driver:
object OracleDriver extends ... {
override def columnTypeRemapper = {
case java.sql.Types.BOOLEAN = java.sql.Types.INTEGER
}
...
}
Thoughts?
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
If I built a special branch to test this out would you be OK with pulling
and building that yourself? Otherwise I can build it and send you the jars.
Thanks,
Derek
On Thu, Jul 23, 2009 at 11:24 PM, Jon jon.klei...@usit.uio.no wrote:
Hi Derek,
For me this sounds fine, but then I'm still a Lift and Scala newbie. I
think the best way is just to try it. ;-)
Whenever you have something that I can try, let me know.
/Jon
On Jul 23, 10:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
OK, I think that this is happening because when we use the JDBC setObject
call, we explicitly send the type. As far as I can tell the Oracle driver
doesn't like java.sql.Types.BOOLEAN *at all*, so I'm trying to determine
the
best way to compensate. I'm not sure how common something like this might
be, so it might be nice to allow the net.liftweb.mapper.Driver class to
provide a partial function that allows the vendor-specific driver to
remap
the type. I would add something like:
abstract class DriverType ... {
def columnTypeRemapper : PartialFunction[Int,Int] = {
case x = x
}
}
and then in the Oracle Driver:
object OracleDriver extends ... {
override def columnTypeRemapper = {
case java.sql.Types.BOOLEAN = java.sql.Types.INTEGER
}
...
}
Thoughts?
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
I should be able to do the pulling and building myself, but a few
directions on how to do it will be necessary. The pulling/building I
can try quite soon, but the actual testing may have to wait a few
days. (I'll let you know.)
/Jon
On Jul 24, 3:41 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
If I built a special branch to test this out would you be OK with pulling
and building that yourself? Otherwise I can build it and send you the jars.
Thanks,
Derek
On Thu, Jul 23, 2009 at 11:24 PM, Jon jon.klei...@usit.uio.no wrote:
Hi Derek,
For me this sounds fine, but then I'm still a Lift and Scala newbie. I
think the best way is just to try it. ;-)
Whenever you have something that I can try, let me know.
/Jon
On Jul 23, 10:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
OK, I think that this is happening because when we use the JDBC setObject
call, we explicitly send the type. As far as I can tell the Oracle driver
doesn't like java.sql.Types.BOOLEAN *at all*, so I'm trying to determine
the
best way to compensate. I'm not sure how common something like this might
be, so it might be nice to allow the net.liftweb.mapper.Driver class to
provide a partial function that allows the vendor-specific driver to
remap
the type. I would add something like:
abstract class DriverType ... {
def columnTypeRemapper : PartialFunction[Int,Int] = {
case x = x
}
}
and then in the Oracle Driver:
object OracleDriver extends ... {
override def columnTypeRemapper = {
case java.sql.Types.BOOLEAN = java.sql.Types.INTEGER
}
...
}
Thoughts?
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
Hey Jon, Sounds like Mapper is not quite sure what to do with one of the types it created - If memory serves Derek is looking after the DB drivers these days (the fellow who wrote oracle driver isn't active anymore), so my advice would be log a issue here so that it doesn't get missed: http://github.com/dpp/liftweb/issues Cheers, Tim On Jul 23, 12:12 pm, Jon Kleiser jon.klei...@usit.uio.no wrote: Hi, I just tried to run the todo app. (http://liftweb.net/docs/getting_started/mod_master.html) against our Oracle (10something) database. The two tables got created like this: INFO - CREATE TABLE users (id ROWID , firstname VARCHAR(32) , lastname VARCHAR(32) , email VARCHAR(48) , locale VARCHAR(16) , timezone VARCHAR(32) , password_pw VARCHAR(48) , password_slt VARCHAR(20) , textarea VARCHAR(2048) , validated NUMBER , uniqueid VARCHAR(32) , superuser NUMBER) INFO - ALTER TABLE users ADD CONSTRAINT users_PK PRIMARY KEY(id) INFO - CREATE TABLE todo (id ROWID , desc_c VARCHAR(128) , done NUMBER , owner NUMBER , priority NUMBER) INFO - ALTER TABLE todo ADD CONSTRAINT todo_PK PRIMARY KEY(id) INFO - CREATE INDEX users_email ON users ( email ) INFO - CREATE INDEX users_uniqueid ON users ( uniqueid ) INFO - CREATE INDEX todo_owner ON todo ( owner ) I then used Oracle's SQLDeveloper to confirm that the tables had been created and had the right columns. However, when I tried to Sign Up in the todo app., I got this nasty stuff right in the browser (nothing in the log): Exception occured while processing /user_mgt/sign_up Message: java.sql.SQLException: Invalid column type oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146) oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208) oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePrepared Statement.java:9262) oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePrepared Statement.java:8843) oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatemen t.java:9316) net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$prepStat$1$1.apply(MetaM apper.scala:622) net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$prepStat$1$1.apply(MetaM apper.scala:616) scala.Iterator$class.foreach(Iterator.scala:414) scala.Iterator$$anon$14.foreach(Iterator.scala:265) scala.Iterable$class.foreach(Iterable.scala:256) scala.collection.mutable.HashMap.foreach(HashMap.scala:33) net.liftweb.mapper.MetaMapper$$anonfun$12.prepStat$1(MetaMapper.scala:616) net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$19.apply(MetaMapper.scal a:659) net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$19.apply(MetaMapper.scal a:659) net.liftweb.mapper.DB$$anonfun$prepareStatement$2.apply(DB.scala:292) net.liftweb.mapper.DB$$anonfun$prepareStatement$2.apply(DB.scala:288) net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241) net.liftweb.util.Helpers$.calcTime(Helpers.scala:29) net.liftweb.mapper.DB$.prepareStatement(DB.scala:288) net.liftweb.mapper.MetaMapper$$anonfun$12.apply(MetaMapper.scala:658) net.liftweb.mapper.MetaMapper$$anonfun$12.apply(MetaMapper.scala:578) net.liftweb.mapper.DB$.use(DB.scala:305) net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:577) com.liftworkshop.model.User$$$M$5d72f813.save(User.scala:9) com.liftworkshop.model.User$$$A$5d72f813.save(generated) com.liftworkshop.model.User$.save(generated) net.liftweb.mapper.Mapper$$anonfun$save$1.apply(Mapper.scala:84) net.liftweb.mapper.Mapper$$anonfun$save$1.apply(Mapper.scala:84) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) net.liftweb.mapper.Safe$.runSafe(Safe.scala:44) net.liftweb.mapper.Mapper$class.runSafe(Mapper.scala:50) com.liftworkshop.model.User$$M$7ee2c84f.runSafe(User.scala:24) com.liftworkshop.model.User$$A$7ee2c84f.runSafe(generated) com.liftworkshop.model.User.runSafe(generated) net.liftweb.mapper.Mapper$class.save(Mapper.scala:83) com.liftworkshop.model.User$$M$7ee2c84f.save(User.scala:24) com.liftworkshop.model.User$$A$7ee2c84f.save(generated) com.liftworkshop.model.User.save(generated) net.liftweb.mapper.MetaMegaProtoUser$class.testSignup$1(ProtoUser.scala:343 ) net.liftweb.mapper.MetaMegaProtoUser$$anonfun$innerSignup$1$1.apply(ProtoUs er.scala:360) net.liftweb.mapper.MetaMegaProtoUser$$anonfun$innerSignup$1$1.apply(ProtoUs er.scala:360) net.liftweb.http.S$NFuncHolder$$anonfun$apply$46.apply(S.scala:941) net.liftweb.http.S$NFuncHolder$$anonfun$apply$46.apply(S.scala:941)
[Lift] Re: todo app., Oracle: Invalid column type
I've now logged it as an issue. /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
Based on this line: oracle.jdbc.driver. OraclePreparedStatement.setObject(OraclePreparedStatement.java:9316) I have a feeling that we're handing an Object to the driver that doesn't map correctly to the type of the column. For instance, we could be handing a Long to something with type DOUBLE. Normally JDBC drivers attempt to coerce the object based on internal mappings but they don't always match up the same between vendors in my experience. In particular, the fact that validated and superuser are being defined as NUMBER (because Oracle's JDBC driver doesn't support boolean, http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.html#34_05) makes me think that we're handing a java Boolean to the driver. I think that this should be a simple fix with an extra case statement in MetaMapper. What version of Lift are you using? 1.0, 1.1-SNAPSHOT, or something else? Thanks, Derek On Thu, Jul 23, 2009 at 8:44 AM, Jon jon.klei...@usit.uio.no wrote: I've now logged it as an issue. /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
I'm using Lift 1.0. /Jon On Jul 23, 5:08 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Based on this line: oracle.jdbc.driver. OraclePreparedStatement.setObject(OraclePreparedStatement.java:9316) I have a feeling that we're handing an Object to the driver that doesn't map correctly to the type of the column. For instance, we could be handing a Long to something with type DOUBLE. Normally JDBC drivers attempt to coerce the object based on internal mappings but they don't always match up the same between vendors in my experience. In particular, the fact that validated and superuser are being defined as NUMBER (because Oracle's JDBC driver doesn't support boolean,http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq) makes me think that we're handing a java Boolean to the driver. I think that this should be a simple fix with an extra case statement in MetaMapper. What version of Lift are you using? 1.0, 1.1-SNAPSHOT, or something else? Thanks, Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: todo app., Oracle: Invalid column type
OK, I think that this is happening because when we use the JDBC setObject
call, we explicitly send the type. As far as I can tell the Oracle driver
doesn't like java.sql.Types.BOOLEAN *at all*, so I'm trying to determine the
best way to compensate. I'm not sure how common something like this might
be, so it might be nice to allow the net.liftweb.mapper.Driver class to
provide a partial function that allows the vendor-specific driver to remap
the type. I would add something like:
abstract class DriverType ... {
def columnTypeRemapper : PartialFunction[Int,Int] = {
case x = x
}
}
and then in the Oracle Driver:
object OracleDriver extends ... {
override def columnTypeRemapper = {
case java.sql.Types.BOOLEAN = java.sql.Types.INTEGER
}
...
}
Thoughts?
Derek
On Thu, Jul 23, 2009 at 9:38 AM, Jon jon.klei...@usit.uio.no wrote:
I'm using Lift 1.0.
/Jon
On Jul 23, 5:08 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
Based on this line:
oracle.jdbc.driver.
OraclePreparedStatement.setObject(OraclePreparedStatement.java:9316)
I have a feeling that we're handing an Object to the driver that doesn't
map
correctly to the type of the column. For instance, we could be handing a
Long to something with type DOUBLE. Normally JDBC drivers attempt to
coerce
the object based on internal mappings but they don't always match up the
same between vendors in my experience. In particular, the fact that
validated and superuser are being defined as NUMBER (because Oracle's
JDBC driver doesn't support boolean,
http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq)
makes me think that we're handing a java Boolean to the driver. I think
that
this should be a simple fix with an extra case statement in MetaMapper.
What version of Lift are you using? 1.0, 1.1-SNAPSHOT, or something
else?
Thanks,
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
