22程序的列数限制 [英] 22 Column limit for procedures

查看:97
本文介绍了22程序的列数限制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用Slick调用过程时如何克服22个限制?

How can we overcome the 22 limit when calling procedures with Slick?

我们目前有:

val q3 = sql"""call getStatements(${accountNumber})""".as[Transaction]

问题在于我们必须返回22列以上,并且Transaction case类的列不能超过22列,因为当我们执行JSONFormat时,会收到错误消息:

The problem is that we have to return more than 22 columns and Transaction case class cannot have more than 22 columns since when we do JSONFormat we get an error:

[error] E:\IdeaProjects\admin\Transaction.scala:59: No unapply or unapplySeq function found
[error]   implicit val jsonFormat = Json.format[Transaction]

有什么建议吗?

推荐答案

好-因此,如果您实际上可以修改Transaction案例类,那么比HList更好的解决方案(说实话可能有点麻烦以后再使用).

Alright - so if you can actually modify your Transaction case class than there is a better solution than HList (which to be honest may be a little cumbersome to operate with later on).

这就是问题:假设您有具有以下属性的User表:

So here is the thing: let's imagine you have User table with following attributes:

  • id
  • 名称
  • 教师
  • finalGrade
  • 街道
  • 号码
  • 城市
  • postCode

以上各列可能没有意义,但让我们以它们为例.上面处理的最直接的方法是创建一个case类:

Above columns may not make sense but let's use them as example. The most straightforward way to deal with above is to create a case class:

case class User(
   id: Long,
   name: String,
   ...  // rest of the attributes here
   postCode: String)

这将从应用程序端的表进行映射.

which would be mapped from table on the application side.

现在您还可以执行以下操作:

Now what you can also do is to do this:

case class Address(street: String, number: String, city: String, postCode: String)

case class UniversityInfo(faculty: String, finalGrade: Double)

case class User(id: Long, name: String, surname: String, uniInfo: UniversityInfo, address: Address)

此组合将帮助您避免列过多的问题(这基本上是案例类/元组中属性过多的问题). 除此之外-我认为如果您有很多列,这样做(总是(经常)是有益的)-如果仅出于可读性目的而已.

This composition will help you to avoid problem with too many columns (which is basically problem with too many attributes in your case class/tuple). Apart from that - I would argue that it is always (very often?) beneficial to do this if you have many columns - if for nothing else than simply for readability purposes.

如何进行映射

class User(tag: Tag) extends Table(tag, "User") {

  // cricoss info
  def id = column[Long]("id")
  def name = column[String]("name")

  // ... all the other fields
  def postCode = column[String]("postCode")

  def * = (id, name, surname, uniInfoProjection, addressProjection) <>((User.apply _).tupled, User.unapply)

  def uniInfoProjection = (faculty, finalGrade) <>((UniversityInfo.apply _).tupled, UniversityInfo.unapply)

  def addressProjection = (street, number, city, city) <>((Address.apply _).tupled, Address.unapply)
}

使用自定义SQL映射可以完成相同的操作.

The same can be done with custom SQL mapping.

implicit val getUserResult = GetResult(r => 
    User(r.nextLong, r.nextString, r.nextString, 
         UniversityInfo(r.nextString, r.nextDouble),
         Adress(r.nextString, r.nextString, r.nextString, r.nextString))
)         


因此,简单地说-尝试将您的字段分成多个嵌套的案例类,您的问题就应该消失了(具有提高的可读性的额外好处).如果这样做的话,接近元组/案例类的限制几乎应该不会成为问题(并且甚至不需要使用HList).

这篇关于22程序的列数限制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆