enums, using methods as initializers

[Stefan Ram]

What I'm looking for is a way to go through all fields and
extract them from the row in a loop.

{ final java.sql.ResultSetMetaData desc = resultSet.getMetaData();
final int cols = desc.getColumnCount();
for( int i = 1; i <= cols; ++i )
java.lang.System.out.println
( desc.getColumnName( i )+ " " + resultSet.getString( i )); }

I have not tested the above code, so it still might contain bugs.
You also can get the type from the meta data. See

http://download.java.net/jdk7/docs/api/java/sql/ResultSetMetaData.html

 

[Roedy Green]

FIELD1 (ResultSet.getString),

You will have to pass a value here. e.g.
OtherClass.resultSet.getString()

You seem to be trying to pass a method as av argument. You can't do
that in Java. See http://mindprod.com/jgloss/callback.html

 

[Mikhail Teterin]

{ final java.sql.ResultSetMetaData desc = resultSet.getMetaData();
final int cols = desc.getColumnCount();
for( int i = 1; i <= cols; ++i )
java.lang.System.out.println
( desc.getColumnName( i )+ " " + resultSet.getString( i )); }

I have not tested the above code, so it still might contain bugs.
You also can get the type from the meta data. See

http://download.java.net/jdk7/docs/api/java/sql/ResultSetMetaData.html

Thank you, that's pretty cool. But that goes through the columns of the
ResultSet. I'm trying to go through the fields of my own Class, however.

I know, I can store the data in my own HashTable, but I would rather access
the fields as entry.foo and entry.meow instead of entry.getFoo() and
entry.getMeow().

Thanks!

-mi

 

[Wayne]

You will have to pass a value here. e.g.
OtherClass.resultSet.getString()

You seem to be trying to pass a method as av argument. You can't do
that in Java. See http://mindprod.com/jgloss/callback.html

Of course you can create a Method object and pass that, and then
invoke it, but I don't think that's what the OP had in mind.

-Wayne

 

[Daniel Pitts]

Thank you, that's pretty cool. But that goes through the columns of the
ResultSet. I'm trying to go through the fields of my own Class, however.

I know, I can store the data in my own HashTable, but I would rather access
the fields as entry.foo and entry.meow instead of entry.getFoo() and
entry.getMeow().

Thanks!

-mi

If you REALLY REALLY want to go through the fields of a class (Bad
Idea), you can use reflection.

Reflection is difficult to get right, so I suggest delegating that
responsibility to a library that is maintained by a large community.
Hibernate does exactly what you want. *Exactly* what you want. Let me
repeat. Hibernate does *exactly* what you're trying to do.

If you insist on going the route of DIY, read my warning about reflection:

<http://virtualinfinity.net/wordpres...angers-of-reflection-or-put-down-that-mirror/>

If after reading that, you feel justified in using reflection, the sun
tutorial on reflection is a good starting place:
<http://java.sun.com/docs/books/tutorial/reflect/index.html>

Just know that I've gone down the road you're trying to. It isn't a
pretty journey, and the destination isn't all that nice either.

 

[Stefan Ram]

Thank you, that's pretty cool. But that goes through the columns of the
ResultSet. I'm trying to go through the fields of my own Class, however.

public class Main
{ public static void main( final java.lang.String[] args )
throws java.lang.Exception
{ class Example { int i; java.lang.String s; };
for( java.lang.reflect.Field field: Example.class.getDeclaredFields() )
java.lang.System.out.println( field.getName() ); }}

i
s

 

[Mikhail Teterin]

If you REALLY REALLY want to go through the fields of a class (Bad
Idea)

Uhm, why? I'm quite sure, we are not alone here with the need to have an
object for every row return by an SQL-query...

you can use reflection.

Well, here is what I cooked up:

http://aldan.algebra.com/~mi/selfsetting/SelfSettingFromSQL.java.html
or
http://aldan.algebra.com/~mi/selfsetting/SelfSettingFromSQL.java

It will set the scalar fields and even arrays. The same java.sql.ResultSet
can be used to create (or set) different objects -- the columns without
matching fields in each object's class will simply be ignored.

A typical use would be to define your own class as "extends
SelfSettingFromSQL".

Hibernate does exactly what you want. Exactly what you want. Let me
repeat. Hibernate does exactly what you're trying to do.

NOW, I can go and look into how someone else has done it

Just know that I've gone down the road you're trying to. It isn't a
pretty journey, and the destination isn't all that nice either.

So far I like it All I need now is declare the data-fields in my classes
and make sure, the SQL-queries return fields with matching names. The
tedious setting of every field (in every one of those classes) is now a
thing of the past.

The information about all the names and the types of all the fields is there
at run-time. Not using it is foolish...

-mi

 

[Mikhail Teterin]

If you REALLY REALLY want to go through the fields of a class (Bad
Idea)

Uhm, why? I'm quite sure, we are not alone here with the need to have an
object for every row return by an SQL-query...

you can use reflection.

Well, here is what I cooked up:

http://aldan.algebra.com/~mi/selfsetting/SelfSettingFromSQL.java.html
or
http://aldan.algebra.com/~mi/selfsetting/SelfSettingFromSQL.java

It will set the scalar fields and even arrays. The same java.sql.ResultSet
can be used to create (or set) different objects -- the columns without
matching fields in each object's class will simply be ignored.

A typical use would be to define your own class as "extends
SelfSettingFromSQL".

Hibernate does exactly what you want. Exactly what you want. Let me
repeat. Hibernate does exactly what you're trying to do.

NOW, I can go and look into how someone else has done it

Just know that I've gone down the road you're trying to. It isn't a
pretty journey, and the destination isn't all that nice either.

So far I like it All I need now is declare the data-fields in my classes
and make sure, the SQL-queries return fields with matching names. The
tedious setting of every field (in every one of those classes) is now a
thing of the past.

The information about all the names and the types of all the fields is there
at run-time. Not using it is foolish...

-mi