You only need dynamic typing because your query is defined as a "dynamic"
string!
The database certainly has a schema and knows the types of columns, as
should your code base with it's own internal DAOs. The problem is the
marshalling in between, JDBC and string-based queries. This isn't too far
removed from the dynamic typing issues caused by defining stuff as
uncompiled raw strings in a Spring context config.
Compare to something like squeryl:
val avg =
from(grades)(g =>
where(g.subjectId === mathId)
compute(avg(g.scoreInPercentage))
)
The compiler *knows* that avg will be an Option[Float], because it knows the
types of the columns. It even checks, statically, that subjectId and mathId
are of the same type; refusing to compile if they aren't.
LINQ also takes a similar approach.
So no, you don't need dynamic typing. Though once you've introduced it (via
SQL query strings) it does tend to get pervasive unless very carefully
controlled.
On 9 May 2011 15:12, phil swenson <[email protected]> wrote:
> What if your sql is "select id as id_alias from users where username
> ='phil'"?
>
> Then the code would be
>
> id = resultset.id_alias
>
>
> I think you need dynamic typing for this sort of thing.
>
>
>
> On Mon, May 9, 2011 at 6:31 AM, Josh Berry <[email protected]> wrote:
> > Couple of questions.
> >
> > First, is dynamic typing truly necessary for this level of coding? I
> > know it is commonly used that way, but I have seen some tricks in
> > static languages that work just as well. (The Lift folks have a good
> > api for pulling from a database, and that is ignoring squeryl. Sadly,
> > I'm ignorant of Haskel libraries for this sort of thing. I'm also
> > more ignorant than I care to be on LINQ.)
> >
> > Secondly, I think this is what was referred to when it was said the
> > majority of "dynamic" programs are actually quite static. (Or would
> > this program work correctly if I renamed that column to
> > "SpecificIdentifier" or some nonsense?) I understand that ResultSet
> > has its type altered for this section of code, but one could have just
> > as easily defined a specific subtype of ResultSet for this section,
> > because it will always require that specific type. Plus side to the
> > latter approach, mistakes can be found at compile time. :)
> >
> >
> >
> > On Sun, May 8, 2011 at 2:21 PM, phil swenson <[email protected]>
> wrote:
> >> Lets say you are iterating through database records and one of columns
> is "id"
> >>
> >> def id = resultSet.id
> >>
> >> Or from the original blog post:
> >>
> >> def books = new XmlSlurper().parse("books.xml")
> >> books.book.each {
> >> println "Title = ${it.title}, Author: ${it.author.@firstname}
> >> ${it.author.@lastname}"
> >> }
> >>
> >> import groovy.sql.Sql
> >> sql = Sql.newInstance("jdbc:mysql://host/db", "username", "password",
> >> "com.mysql.jdbc.Driver")
> >> sql.eachRow("select * from tableName", { println it.id + " --
> >> ${it.firstName} --"} )
> >>
> >>
> >>
> >> On Sun, May 8, 2011 at 11:25 AM, Josh Berry <[email protected]> wrote:
> >>> On Sun, May 8, 2011 at 9:30 AM, phil swenson <[email protected]>
> wrote:
> >>>> well the article was called "java.next()"
> >>>>
> >>>> But why not have the best of both worlds? Static typing/type
> >>>> inference. Optional dynamic typing where it makes sense.
> >>>
> >>> Within a given program, I'm curious of an example where dynamic typing
> >>> actually "makes sense." Wasn't there a study that showed even in
> >>> traditional dynamic languages, the majority of the runtime behavior
> >>> was consistent with a static type model?
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to
> [email protected].
> >>> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
> >>>
> >>>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> [email protected].
> >> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> [email protected].
> > For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
Kevin Wright
gtalk / msn : [email protected]
<[email protected]>mail: [email protected]
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side of
the ledger" ~ Dijkstra
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
