我使用CRUDify将一个小型Lift应用程序放在一起,在某些数据库表上执行基本的CRUD操作。
多个列的类型为" CHAR (1 byte)
",用于存储" Y
"的值。或" N
"。我的模型类定义了这个例子的字段:
...
object isActive extends MappedEnum(this, YesNo) {
override def dbColumnName = "IS_ACTIVE"
override def displayName = "Active"
}
...
该类型," YesNo
"是一个Scala对象,定义如下:
object YesNo extends Enumeration {
val Y, N = Value
}
在CRUDify自动生成的网络浏览器表单中,此类列显示为" Y
"和" N
"作为可用选项。但是,当您创建或编辑行时...实际存储的是" 1
"或" 0
"!
Y
"或" N
"在浏览器中, 和 存储" Y
"或" N
"在数据库中?
答案 0 :(得分:0)
嗯...... StackOverflow上没有一个巨大的Scala / Lift社区!实际上,在任何地方,这个“CRUDify”子组件可能没有太多的社区。 p>
无论如何,我最终通过订阅“liftweb”Google网上论坛邮件列表找到了答案(sorta)。显然,这是CRUDify框架中的已知限制。多年来一直如此,并不是任何人特别关心的限制,但它是众所周知的。
2009年,一位开发人员试图通过创建自己的自定义子类MappedField
来找到解决方法,并将其用作Lift模型类中的映射类型。 140行课程以及简要描述它的电子邮件可在以下网址找到:
http://groups.google.com/group/liftweb/browse_frm/thread/34560f30fab299a7/cdca54c8e1486237?pli=1
我不确定这是否在2009年100%有效,当我在2012年尝试使用它时它有很多问题(Scala和Lift在过去三年中都发生了很大变化)。
我投入了少量时间来尝试使这个MappedField
子类工作......然后获得批准选择除CRUDify之外的方法。这个小应用程序的部分任务是学习一些关于如何做什么以及什么不与Lift有关的事情,我认为我们现在完成了任务的这一部分。 :)
但是,如果这项研究和示例代码稍后帮助其他人下线,那就太棒了。