The easiest framework for Java Database applications developmentreleased for production use

[yaormaAdmin]

YaORMa has been released for production use!

Yaorma is the easiest way to get started creating Java database
applications. Yaorma is also robust enough for mission critical large
scale production commercial products. Yaorma has been deployed and
proven in applications developed by single engineers as well as large
enterprise systems produced by dynamic software development teams.

Please visit www.yaorma.org for all of the details!

Thanks,
The YaORMa Team

 

[Lew]

yaormama@Ämail.con says...

There seems to be absolutely NOTHING special about the code snippet on
your product's home page. Forgive me for being ignorant, but I don't get
what the big deal is.

The big deal is that the vapor-vendors at Yamorama think they're all that by
spamming newsgroups, but they aren't.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[John B. Matthews]

There seems to be absolutely NOTHING special about the code snippet
on your product's home page. Forgive me for being ignorant, but I
don't get what the big deal is.

The big deal is that the vapor-vendors at Yamorama think they're all
that by spamming newsgroups, but they aren't.[/QUOTE]

Browsing <http://www.yaorma.org/pages/details.html>, I was intrigued by
the following diagram under "Data Persistence Encapsulation:"

<http://www.yaorma.org/pages/introduction/introduction_files/image008.jpg>

 

[yaormaAdmin]

yaormama@Ämail.con says...

There seems to be absolutely NOTHING special about the code snippet on
your product's home page. Forgive me for being ignorant, but I don't get
what the big deal is.

The big deal is that the vapor-vendors at Yamorama think they're all that by
spamming newsgroups, but they aren't.

--
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Thanks for the feedback. The special bit in the code shown on the
front page is in the Database.getData(sqlString, conn) call.
Basically it encapsulates the boilerplate code that opens the cursor
on the database side (e.g by creating a Statement and a ResultSet).
Often in large projects someone, somewhere, inevitably forgets to
close the Statement and/or the Resultset in a finally block where an
exception is thrown. This results in a cursor being left open in the
database. Eventually the code is executed enough times to exhaust the
maximum number of cursors allowed for the connection. The next call
that opens a cursor in the database fails. This is often not the
offending code but some perfectly good code that exists in some other
far off place in the code.

Since yaorma encapsulates all of this boilerplate code (i.e. the
allocation and deallocation of the Statement and Resultset objects and
the opening and closing of the database cursors) this type of error is
prevented. Also, its easier to get the data in the single
Database.getData(sqlString, conn) call than to write the boilerplate
code to create the statement, create the result set, iterate through
the result set, marshal the data into some type of data object, close
the result set in a finally block, close the statement in a finally
block, etc.

The pages in the more details link (http://www.yaorma.org/pages/
details.html) at the bottom of the homepage go into some of this stuff
as well as some of the other functionality including parametrized
queries, the generation and use of data value objects, marshaling data
from web pages, and marshaling data from the database in constant
space (e.g. for large data sets) etc.

Hope this helps,
John

 

[Lew]

Thanks for the feedback. The special bit in the code shown on the
front page is in the Database.getData(sqlString, conn) call.
Basically it encapsulates the boilerplate code that opens the cursor
on the database side (e.g by creating a Statement and a ResultSet).
Often in large projects someone, somewhere, inevitably forgets to

Fire that person. There's nothing "inevitable" about such a rookie mistake.

close the Statement and/or the Resultset in a finally block where an

<http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#close()>
"Note: When a Statement object is closed, its current ResultSet object, if one
exists, is also closed."

exception is thrown. This results in a cursor being left open in the
database. Eventually the code is executed enough times to exhaust the
maximum number of cursors allowed for the connection. The next call
that opens a cursor in the database fails. This is often not the
offending code but some perfectly good code that exists in some other
far off place in the code.

How "often" does that happen? What statistical basis do you have for such a
claim? Where is your evidence?

Since yaorma encapsulates all of this boilerplate code (i.e. the
allocation and deallocation of the Statement and Resultset objects and
the opening and closing of the database cursors) this type of error is
prevented. Also, its easier to get the data in the single
Database.getData(sqlString, conn) call than to write the boilerplate

And what if you aren't ready to deallocate the Statement?

code to create the statement, create the result set, iterate through
the result set, marshal the data into some type of data object, close
the result set in a finally block, close the statement in a finally
block, etc.

You make it sound much harder than it really is. Remember, closing the
'Staztement' also closes the 'ResultSet'? Of course, being a helpful API
write, surely you knew that already. If you didn't, how could we trust your
API given that level of ignorance?

Marshaling the data is not boilerplate. It depends on the particular data to
marshal, i.e., the structures of the tables and entities. Iteration is all of
one expressions, rs.next(), in a loop condition.

The 'try' ... 'finally' is embedded into the subconscious of every competent
Java programmer. Taking away control of that from the programmer is not
usually a good thing.

The pages in the more details link (http://www.yaormama.orÄ/pages/
details.html) at the bottom of the homepage go into some of this stuff
as well as some of the other functionality including parametrized
queries, the generation and use of data value objects, marshaling data
from web pages, and marshaling data from the database in constant
space (e.g. for large data sets) etc.

How well does this sliced-bread thingie work with JPA?

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[yaormaAdmin]

Thanks for the feedback. The special bit in the code shown on the
front page is in the Database.getData(sqlString, conn) call.
Basically it encapsulates the boilerplate code that opens the cursor
on the database side (e.g by creating a Statement and a ResultSet).
Often in large projects someone, somewhere, inevitably forgets to

Fire that person.  There's nothing "inevitable" about such a rookie mistake.

close the Statement and/or the Resultset in a finally block where an

<http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#...()>
"Note: When a Statement object is closed, its current ResultSet object, if one
exists, is also closed."

exception is thrown.  This results in a cursor being left open in the
database.  Eventually the code is executed enough times to exhaust the
maximum number of cursors allowed for the connection.  The next call
that opens a cursor in the database fails.  This is often not the
offending code but some perfectly good code that exists in some other
far off place in the code.

How "often" does that happen?  What statistical basis do you have for such a
claim?  Where is your evidence?

Since yaorma encapsulates all of this boilerplate code (i.e. the
allocation and deallocation of the Statement and Resultset objects and
the opening and closing of the database cursors) this type of error is
prevented.  Also, its easier to get the data in the single
Database.getData(sqlString, conn) call than to write the boilerplate

And what if you aren't ready to deallocate the Statement?

code to create the statement, create the result set, iterate through
the result set, marshal the data into some type of data object, close
the result set in a finally block, close the statement in a finally
block, etc.

You make it sound much harder than it really is.  Remember, closing the
'Staztement' also closes the 'ResultSet'?  Of course, being a helpful API
write, surely you knew that already.  If you didn't, how could we trust your
API given that level of ignorance?

Marshaling the data is not boilerplate.  It depends on the particular data to
marshal, i.e., the structures of the tables and entities.  Iteration is all of
one expressions, rs.next(), in a loop condition.

The 'try' ... 'finally' is embedded into the subconscious of every competent
Java programmer.  Taking away control of that from the programmer is not
usually a good thing.

The pages in the more details link (http://www.yaormama.orÄ/pages/
details.html) at the bottom of the homepage go into some of this stuff
as well as some of the other functionality including parametrized
queries, the generation and use of data value objects, marshaling data
from web pages, and marshaling data from the database in constant
space (e.g. for large data sets) etc.

How well does this sliced-bread thingie work with JPA?

--
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

What would the code you would write to get the data from the
message_table and echo it to the console in the example at www.yaorma.org
look like?

 

[Lew]

--
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Please don't quote sigs.

What would the code you would write to get the data from the
message_table and echo it to the console in the example at www.yaormama.orġ
look like?

Let's take turns. Instead of merely answering my questions with a
question, how about you answer my questions first? Then I'll answer
yours.

I do appreciate that you're engaging in the conversation. That raises
your credibility in this community. But be fair - I asked questions,
showing my interest, and you have not answered one of them.

I don't know if the example you're citing addresses one scenario I
brought up, namely the desire to hold a statement open for more than
one ResultSet. Nor do I know how you address the comment that copying
data out of a ResultSet is not boilerplate, as it varies with each
different table and associated entity. Nor do I know if it addresses
how your stuff works with JPA, or why it would, or how it might be
preferable. Two people now have raised that question.

I won't go to your site right now - my quick look at it to date has
underwhelmed me. How about you just make your point(s) here in this
forum and back off on the attempts to raise your site's stats?

 

[yaormaAdmin]

Thanks for the feedback. The special bit in the code shown on the
front page is in the Database.getData(sqlString, conn) call.
Basically it encapsulates the boilerplate code that opens the cursor
on the database side (e.g by creating a Statement and a ResultSet).
Often in large projects someone, somewhere, inevitably forgets to

Fire that person. There's nothing "inevitable" about such a rookie
mistake.
Reply: I often work with people who do make these types of mistakes
and often in a collaborative environment where I'm not able to make
the call to fire the person. Also, we often need to continue to
invest in the person we have even after they make mistakes rather than
start all over in the process of bringing someone up to speed on our
specific domain as well as up to speed on basic Java and basic coding
principles and best practices. The Yaorma code shown on the home
pages aims to eliminate this one specific type of error that is
particularly difficult to track down because it often does appear as
and effect at a distance error.

close the Statement and/or the Resultset in a finally block where an

<http://download.oracle.com/javase/6/docs/api/java/sql/
Statement.html#...()>
"Note: When a Statement object is closed, its current ResultSet
object, if one
exists, is also closed."
Reply: Fair enough.

exception is thrown. This results in a cursor being left open in the
database. Eventually the code is executed enough times to exhaust the
maximum number of cursors allowed for the connection. The next call
that opens a cursor in the database fails. This is often not the
offending code but some perfectly good code that exists in some other
far off place in the code.

How "often" does that happen? What statistical basis do you have for
such a
claim? Where is your evidence?
Reply: Yup, this is based entirely upon my experience. I have seen
this type of error often (at least half a dozen times in the past few
years) in my own personal experience. I don't have the resources to
conduct a formal study to find out exactly how often this occurs. If
you've never seen this type of problem come up in a large scale
database project I'd consider you lucky or privileged to work with
nothing but very disciplined knowledgeable coders in a very robust
processes or both.

Since yaorma encapsulates all of this boilerplate code (i.e. the
allocation and deallocation of the Statement and Resultset objects and
the opening and closing of the database cursors) this type of error is
prevented. Also, its easier to get the data in the single
Database.getData(sqlString, conn) call than to write the boilerplate

And what if you aren't ready to deallocate the Statement?
Reply: The code on the homepage address a very simple example. For
process that require a more complex use of the data an alternative
(slightly, but only by a little) method is provided by the framework.
Basically it is an ioc pattern that has the client code call the
framework to get the data and then process the data through an
implementation of an interface.

code to create the statement, create the result set, iterate through
the result set, marshal the data into some type of data object, close
the result set in a finally block, close the statement in a finally
block, etc.

You make it sound much harder than it really is. Remember, closing
the
'Staztement' also closes the 'ResultSet'? Of course, being a helpful
API
write, surely you knew that already. If you didn't, how could we
trust your
API given that level of ignorance?
Reply: Source code is available for review from source forge.

Marshaling the data is not boilerplate. It depends on the particular
data to
marshal, i.e., the structures of the tables and entities. Iteration
is all of
one expressions, rs.next(), in a loop condition.
Reply: Marshaling data isn't always boilerplate but often can be. In
the simple case shown on the homepage the data are simply marshaled
into an array of hashes. Each row in the array is a hash. The key to
each hash is the name of the column in the database table converted to
a standard Java naming convention (_s are removed and camel case is
applied so message_table becomes messageTable). This is similar to
what is often done in languages such as Perl. Using this methodology
assumes a reasonably small data set will be returned from the database
(i.e. all of the data are marshaled before moving on to any processing
of the data). Examples for handling large data sets is also given as
an example on the web site (not trying to drive traffic to the site
here, I just need to get back to my day job).

The 'try' ... 'finally' is embedded into the subconscious of every
competent
Java programmer. Taking away control of that from the programmer is
not
usually a good thing.
Reply: fair enough.

The pages in the more details link (http://www.yaormama.orÄ/pages/
details.html) at the bottom of the homepage go into some of this stuff
as well as some of the other functionality including parametrized
queries, the generation and use of data value objects, marshaling data
from web pages, and marshaling data from the database in constant
space (e.g. for large data sets) etc.

How well does this sliced-bread thingie work with JPA?

Reply:
It is much simpler than JPA.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Lew]

Thank you for your cogent, relevant and helpful answers.

How well does this sliced-bread thingie work with JPA?

Reply:
It is much simpler than JPA.

The question was how well it works *with* JPA.

I'll take a look later on at the example about which you asked.

--

Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Please don't quote sigs.

 

[yaormaAdmin]

....also, some of the examples we have posted are very much geared
towards web applications. There isn't a good example of the method
that uses the interface mentioned above. I'll put one together and
try to get it posted before I go to bed tonight.

Thanks again for all of your feedback, it has been very helpful.

John

 

[Arne Vajhøj]

Thanks for the feedback. The special bit in the code shown on the
front page is in the Database.getData(sqlString, conn) call.
Basically it encapsulates the boilerplate code that opens the cursor
on the database side (e.g by creating a Statement and a ResultSet).
Often in large projects someone, somewhere, inevitably forgets to
close the Statement and/or the Resultset in a finally block where an
exception is thrown. This results in a cursor being left open in the
database. Eventually the code is executed enough times to exhaust the
maximum number of cursors allowed for the connection. The next call
that opens a cursor in the database fails. This is often not the
offending code but some perfectly good code that exists in some other
far off place in the code.

Since yaorma encapsulates all of this boilerplate code (i.e. the
allocation and deallocation of the Statement and Resultset objects and
the opening and closing of the database cursors) this type of error is
prevented. Also, its easier to get the data in the single
Database.getData(sqlString, conn) call than to write the boilerplate
code to create the statement, create the result set, iterate through
the result set, marshal the data into some type of data object, close
the result set in a finally block, close the statement in a finally
block, etc.

So it is more like MS DAAB than an ORM?

Arne

 

[Arne Vajhøj]

Fire that person. There's nothing "inevitable" about such a rookie mistake.

That can be a bit late.

<http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#close()>

"Note: When a Statement object is closed, its current ResultSet object,
if one exists, is also closed."

It does not cost much to call close instead of hoping the JDBC
driver implementator read the specs and the API docs.

How "often" does that happen? What statistical basis do you have for
such a claim? Where is your evidence?

ResultSet's are probably very rare.

Connection's happen.

And what if you aren't ready to deallocate the Statement?

The philosophy in this type of library is not to cover everything,
but to cover 90-95% of the cases.

Those with more advanced requirements will have to look elsewhere.

How well does this sliced-bread thingie work with JPA?

Given that it is not an ORM, then .....

Arne

 

[Arne Vajhøj]

The philosophy in this type of library is not to cover everything,
but to cover 90-95% of the cases.

Those with more advanced requirements will have to look elsewhere.

This is how DAAB especially the early versions work.

See:
http://www.4guysfromrolla.com/articles/070203-1.aspx
for an example of how that was presented.

The code is C#, but the difference from Java is negligible
for this code.

Arne

 

[Lew]

What would the code you would write to get the data from the
message_table and echo it to the console in the example at www.yaorma.org
look like?

You assume I would write code like that. I wouldn't, normally. In a toy
example where everything fits in one 'main()' call, there's not much you can
conclude about the utility of a framework.

The question isn't whether you can simplify a single call to a database for a
single hard-coded query. The question is whether you can build a robust,
stable, extendible application backed by a database. Knocking away a couple
of 'close()' calls is of minor value in such a context.

But to answer your question for the toy example, something similar to

public class Foo
{
@PersistenceContext( unitName = "pcontext" )
private EntityManager em;

public List <Message> findMessages()
{
final CriteriaQuery <Message> cq =
em.getCriteriaBuilder().createQuery( Message.class );

cq.select( cq.from( Message.class ));

return em.createQuery( cq ).getResultList();
}

public static void main( String [] args )
{
System.out.println( new Foo().findMessages() );
}
}

Or I might use a JQL query instead of the 'CriteriaQuery'. It's just that the
criteria approach is amenable to generic treatment - my actual code has a type
parameter for the 'Message' type.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[yaormaAdmin]

Thanks for the comments Arne,

Yup, the stuff discussed on the main page of the yaorma site as well
as in this thread doesn't touch on the object relational mapping piece
of yaorma. There is an ORM generator available as part of the yaroma
framework. The "Generate ORM link" takes you to a page that describes
how to generate the ORM classes. Again, the approach with the ORM
generator is to create a simple mapping of simple 1:1 data value
objects for database tables and views. Loading of the data into the
data objects in code that uses the data value objects can be handled
by the Dao (data access object) class of the framework. That code
would look something like the example from the database query link:

// StateDvo is a data value object that is essentially a 1:1 mapping
of the state database table
String sqlString = "select * from state order by state_name";
Data data = Database.query(sqlString, conn);
ArrayList<StateDvo> stateList = Dao.load(StateDvo.class, data);
request.setAttribute("stateList", stateList);
this.nextUrl = request.getParameter("nextUrl");

John

 

[yaormaAdmin]

Hi Everybody,

This is what code that needs to either process the result set as it is
fetched (e.g. larger data sets) or needs to do something more with the
data might look like. The necessary database resources will be
allocated and deallocated by the framework immediately prior to and
immediately after the call to echoToConsole. The choice to use
reflection rather than an interface was driven by the need to have any
number of database data processing calls in a single class. This is a
complete example that should compile and run with out any additional
hand written code (given the existence of the underlying database) and
with only the database driver jar and the yaorma jar.

Sorry I won't be able to post the complete example to the web site
tonight but I'll get it there as soon as I can.

Thanks again for all of your help and feedback,
John

----8<-----------------8<-----------------

package org.yaorma.examples.resultSetUser.main;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;

import org.yaorma.database.Data;
import org.yaorma.database.Database;

public class YaormaDataUserExample {

public static void main(String[] args) throws Exception {
new YaormaDataUserExample().exe();
}

public void exe() throws Exception {
// some configuration parameters
String dbDriverClassName = "oracle.jdbc.driver.OracleDriver";
String dbUrl = "jdbcracle:thinlocalhost:1521rcl";
String dbUid = "guest";
String dbPwd = "guestpwd";

// get a connection
Class.forName(dbDriverClassName);
Connection conn = DriverManager.getConnection(dbUrl, dbUid, dbPwd);

// use yaorma to get the database data
String sqlString = "select * from test_table order by row_id";
Database.query(this, "echoToConsole", conn, sqlString);

// done
System.out.println("Done!");

}

public void echoToConsole(ResultSet rs) throws Exception {
while(rs.next()) {
System.out.print(rs.getString("row_id"));
System.out.print(rs.getString("message"));
System.out.print("\n");
// use the data in any way you choose here
}
}

}

 

[yaormaAdmin]

Thanks for the link to DAAB Arne. I'll give it a closer look when I
get a chance!

John

 

[Arne Vajhøj]

Thanks for the link to DAAB Arne. I'll give it a closer look when I
get a chance!

It is .NET and not directly applicable.

But it seems to me that your approach and DAAB (especially in
early versions) share some philosophy.

Arne

 

[Wojtek]

yaormaAdmin wrote :

Often in large projects someone, somewhere, inevitably forgets to
close the Statement and/or the Resultset in a finally block where an
exception is thrown. This results in a cursor being left open in the
database. Eventually the code is executed enough times to exhaust the
maximum number of cursors allowed for the connection. The next call
that opens a cursor in the database fails. This is often not the
offending code but some perfectly good code that exists in some other
far off place in the code.

Or you could just use a connection pool manager such as proxool. Use
proxool to log into the database and then it manages all of that. DB
connections which are idle for a given number of milliseconds are
automatically closed. So all of the extra coding to fit yet another
framework is not needed

Plus you get far better DB performance under load as you do not need
the expensive connection establishment for every DB operation.

 

[yaormaAdmin]

yaormaAdmin wrote :


Or you could just use a connection pool manager such as proxool. Use
proxool to log into the database and then it manages all of that. DB
connections which are idle for a given number of milliseconds are
automatically closed. So all of the extra coding to fit yet another
framework is not needed

Plus you get far better DB performance under load as you do not need
the expensive connection establishment for every DB operation.

Thanks for the comments Wojtek. In the example code the connection is
instantiated using the DriverManager just to make the example simpler
(and so it stands on its own, without needing additional
dependencies). The Yaorma framework has been used in several
applications using pooled connections. Most of this work has used
Tomcat and would only run inside some sort of container. I'll look
into Proxool more, thanks for the tip. What would you consider the
gold standard for a connection pool for a desktop/rich client (Swing,
RCP, etc.) application?

Thanks again,
John