Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Expanding on my earlier comment regarding <code>HList</code>s: (This was too big for a comment, so posting it as an answer.)</p> <p>I am using Scala for the code examples, as it has a good support for the idea being discussed. All the code examples are typed at console.</p> <p>When you have an object of type <code>Dog</code>, and another object of type <code>Tiger</code>, if you put them in a same covariant list, the resulting list will have type <code>List[Animal]</code> where <code>Animal</code> is their common super type. The original types are lost because this list is homogeneous. Notice the inferred type of list below:</p> <pre><code>scala&gt; class Animal defined class Animal scala&gt; class Dog extends Animal defined class Dog scala&gt; class Tiger extends Animal defined class Tiger scala&gt; List(new Tiger, new Dog) res0: List[Animal] = List(Tiger@a32604, Dog@1150b68) </code></pre> <p>Similarly <code>Verifier[Int]</code> and <code>Verifier[String]</code> when put in a single homogeneous list will assume type <code>Verifier[Any]</code>. (In Scala, <code>Any</code> class lies at the top of the object hierarchy.) See:</p> <pre><code>scala&gt; class Verifier[+T](value: T) { | override def toString = "Verifier(" + value.toString + ")" | } defined class Verifier scala&gt; List(new Verifier(6), new Verifier("hello")) res1: List[Verifier[Any]] = List(Verifier(6), Verifier(hello)) </code></pre> <p>If you want to preserve the static types, and use them for computations latter, you should use heterogeneous list. Or <code>HList</code> for short. </p> <pre><code>scala&gt; new Verifier(6) :: new Verifier("hello") :: HNil res2: shapeless.::[Verifier[Int],shapeless.::[Verifier[java.lang.String],shapeless.HNil]] = Verifier(6) :: Verifier(hello) :: HNil </code></pre> <p>Here is how polymorphic mapping works with that:</p> <pre><code>scala&gt; class Parameter[+T](value: String, verif: Verifier[T]) { | override def toString = "P(" + value + ", " + verif + ")" | } defined class Parameter scala&gt; object mapper extends (Verifier ~&gt; Parameter) { | def apply[A](v: Verifier[A]): Parameter[A] = new Parameter("k", v) | } defined module mapper scala&gt; res2 map mapper res3: mapper.Out = P(k, Verifier(6)) :: P(k, Verifier(hello)) :: HNil </code></pre> <p>We preserved the type parameters, and acted upon each element of the list with the given higher-ranked function. That gave us back a <code>HList</code> of <code>Parameter</code>s where the correct types were preserved.</p> <p>Note that the concept of <code>HList</code> can be implemented in Java, but you cannot define many useful operations on the structure. Java's type system isn't capable of it. <a href="http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the-limits-of-the-java-type-system/" rel="nofollow">Here</a> is a great article on the topic, if you are interested.</p> <p>Hope this is helpful in some way.</p>
    singulars
    1. This table or related slice is empty.
    1. POGet generic type of one class to create another generic class
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USmissingfaktor
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COIt's interesting, but the java equivalent is completely nonsensical. Type erasure is a general issue in java, but the HList concept for it is not usable. Also consider: I'm only using String and integer as examples. I could have 100s of different types of checker, including several of the same type but applicable to different situations, depending on the usage. Maybe in Java 8 huh?
      singulars
      1. PO
      1. USK.Barad
    2. CO@K.Barad, type erasure is irrelevant here. It's the lack of type inference that makes HList unusable in Java. (Rather, it's one of the many reasons.)
      singulars
      1. PO
      1. USmissingfaktor
    3. CO@K.Barad, HList operations require several type system features Java lacks. (Higher kinds, type-classes, declaration-site variance to mention a few.) Java-8 won't help much.
      singulars
      1. PO
      1. USmissingfaktor
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload