Show database list at Redshift

If you want to show the list of databases, you can use pg_database or pg_database_info table, which are included the standard PostgreSQL catalog tables.

SELECT * FROM pg_database;

select datname, datdba, datconnlimit from pg_database_info where datdba > 1;

pg_database_extended


References
System Catalog Table / Amazon Redshift Docs
https://docs.aws.amazon.com/redshift/latest/dg/c_intro_catalog_views.html
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_intro_catalog_views.html

System Catalogs

https://www.postgresql.org/docs/8/catalogs.html

https://www.postgresql.org/docs/8/catalog-pg-database.html

ScalaMatsuri 2016 A1 Refactoring in Scala

ScalaMatsuri 2016は大盛況のうちに幕を閉じました。私もスタッフとして参加しておりました。

さて、ScalaMatsuri2016のA会場で行われた、基調講演たるがくぞさんのセッションの内容を簡単にまとめたので共有します。




【値オブジェクトに使える値の型4選】

  1. Type Alias(簡単、意味が明確にできる。だが型安全でない)
  2. Tagged Type(型安全だ。しかし数値型だとboxing/unboxingが発生してしまう)
  3. Value Class(boxing/unboxing発生しない。しかし定義するのが面倒)
  4. Phantom Type(http://gakuzzzz.github.io/slides/refactoring_in_scala/#27

【Phantom Typeはちょっとコツがいる。導入のための手順は以下のとおり】

  • DBの取り扱い可能な値型との相互変換が問題となる
  • したがってPrismまたはIsoを導入する(相互変換のためのパターン)
    • DB側でPrismの扱いを定義する
    • それぞれの値オブジェクトでPrismを継承する
      • ボイラープレートだ
      • experimentalだがmacroを使えればボイラープレートがなくなる



といったトークがあり、(独断と偏見で)まとめると以下の表のようになります


Type Alias
Tagged Type
Value Class
Phantom Type
Phantom Type & Prism & macro
導入コスト
◎:他のロジックに影響ない
×:定義が面倒
△:macroはまだExperimental
型安全
×
コンテナ型へのキャスト
×
×
追加のメソッド定義
×
×
boxing/unboxing
×:AnyValだとアカン
レイヤー境界での変換が不要(DBなどとの互換性)
×
×
×


こんなにわかりやすい発表資料もなかなかないと思います。

急いで作ったのでミスあると思いますが、その際はどうぞお知らせください。-> https://twitter.com/NoriakiHoriuchi

java.lang.IllegalArgumentException

以下のエラーと長いStacktraceが出力されてどうしたものかと思ったが、ここで示されているList内にパッケージ内のどこでエラーが出ているのかが書いてあったおかげで救われました。


[error] (compile:compileIncremental) java.lang.IllegalArgumentException: Could not find proxy for model: models.MyModel in List(value model, method apply, <$anon: Function1>, method myMethod, class MyClass, package myPackage, package services, package <root>) (currentOwner= value x$11 )

List(value model, method apply, <$anon: Function1>, method myMethod, class MyClass, package myPackage, package services, package <root>) とあるので、末尾から逆に辿って _root_.services.myPackage.MyClass に定義されているmyMethod内の引数一つの無名関数のどこかにおかしいところがあります。

原因は myMethod 内で使用していた Optionfold[B](ifEmpty: => B)(f: A => B) について、第一引数 ifEmpty を指定し忘れていたからでした。

改行して中にコメントを追加していたのでIDEも検知できなかったようです(?)。

foreach するなり、 for 内包表記で処理するという対処法があります。また、Unitを返すべき場面では () を追加するという方法もあります。

Scalaのクラスのコンストラクタに、空の括弧(Empty Parentheses)をつけて定義すべきかどうか?結論:どちらでもいい

「引数を取らないメソッドに対して、空の括弧(empty paren)をつけて定義するか?それともつけずに定義するか?」は、副作用があるかどうかで決めるのがScalaの流儀であります。これと同様に、クラスのコンストラクタも引数を取らないときには括弧をつけるパターンとつけないパターン、いずれの方法でも定義することができます。そうなると果たしてどうやって括弧をつけるかどうか判断すべきなのか?というのが今回のテーマです。

じっさい公式のスタイルガイドにはそのような項目がないので、どうするかは各人に任されているようなのですが、StackOverflowにはドンピシャな質問があります。

Scala style for empty class parameter lists

ベストアンサーの方の回答を要約すると

  1. Javaでクラス(括弧あり)とインターフェースを見分けるために使っているように、Scalaでもクラス(空の括弧あり)とトレイトで使い分けてもいい

  2. メソッドと同様に、副作用があるならつける、ないならつけないということもできる

    • でもコンストラクタでは副作用が発生しないのが理想だよな…
  3. 状態を持つオブジェクト、ミュータブルなオブジェクト(空の括弧つける)とイミュータブルなオブジェクト(括弧つけない)で使い分けるということもできる

    • でもケースクラスはイミュータブルであるべきだが、空の括弧をつけずに定義するのは非推奨だし…
  4. 個人的にはない方が見やすいから付けてないよ

ということです。

個人的にも、わざわざ付ける必要はないと思っています。

Scalaのcase classの第二パラメータリストに外からアクセスできなくて困った件

ケースクラスの2つ目の引数が外から見えない、なぜだろう?ということが発端となり、いろいろと調べたりGitterで質問してみました。その結果、コンストラクタ引数の定義のしかたによって見え方(アクセス修飾子の状態)が異なるということがわかりました。


scala> case class A(x: Int)(y: Int){

     | def printY() = println(y)

     | }

defined class A

scala> val a = A(10)(20)

a: A = A(10)

scala> a.x

res22: Int = 10

scala> a.y

<console>:19: error: value y is not a member of A

              a.y

                ^

scala> a.printY()

20

クラスののデフォルトコンストラクタ引数はprivateです。したがって、下の例ではprivateなフィールドxにアクセスしようとしてエラーが出ています。


scala> class A(x: Int)

defined class A

scala> new A(10)

res0: A = A@af23093

scala> res0.x

<console>:13: error: value x is not a member of A

       res0.x

            ^

scala> 

私は普段case classをよく使う一方、クラスのフィールドに外からアクセスすることはあまりないので、すっかり頭のなかから抜け落ちていました。

このフィールドをpublicなものとするには、 val または var を明示的に付けてあげる必要があります。


scala> class A(val x: Int)

defined class A

scala> new A(10)

res0: A = A@6deaf732

scala> res0.x

res1: Int = 10

あるいは、case classとすると、valやvarを付加しなくても自動生成されたゲッターメソッドによってフィールドにアクセスできます。


scala> case class A(x: Int)

defined class A

scala> A(10)

res0: A = A(10)

scala> res0.x

res1: Int = 10

しかしながら、case classは万能ではありません。case classに複数のパラメータリストが存在する場合、2つ目以降のパラメータリストにはゲッターメソッドを生成してくれません。


scala>  case class B(x: Int)(y: Int)(z: Int)

defined class B

scala> B(10)(20)(30)

res0: B = B(10)

scala> res0.x

res1: Int = 10

scala> res0.y

<console>:14: error: value y is not a member of B

       res0.y

            ^

scala> res0.z

<console>:14: error: value z is not a member of B

       res0.z

            ^

それどころか、case classはequals()やhashCode()についても2つ目以降のパラメータリストを無視してくれるので、以下のように「第一パラメータだけで比較する」「ハッシュコードが同一になる」といった現象が起こります。
https://gitter.im/scalajp/public


scala> case class C(x: Int)(y: Int)

defined class C

scala> C(10)(20)

res0: C = C(10)

scala> C(10)(30)

res1: C = C(10)

scala> res0 == res1

res2: Boolean = true

scala> res0.hashCode

res3: Int = -2008924253

scala> res1.hashCode

res4: Int = -2008924253

結論:気をつけます。

参考


http://www.ne.jp/asahi/hishidama/home/tech/scala/class.html#h_construntor


http://www.ne.jp/asahi/hishidama/home/tech/scala/class.html#h_case_class