| Newsgroups |
gmane.comp.java.orm.simpleorm |
| Message-ID |
<[email protected]> |
--------------050209070004000200020108
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Just as a side note, for thoses using Spring Framework, you can also
have a look at https://launchpad.net/mkorm
This project aims at facilitating the use of Simpleorm
(www.simpleorm.org) in Springframework, especially by implementing the
Template strategy.
It make it easier to get the try / catch / finally boilerplate done
well, use Spring's annotated transactions, etc.
So you can write things like this:
public List<Myrecord> getRecordList(String attr) {
SQuery<Myrecord> qry = new SQuery<Myrecord>(Myrecord.meta)
.eq(Myrecord.attribute, attr);
return getSormTemplate().query(qry);
}
or more elaborated:
public int getMinLevel(final String attr) {
SormCallback<SRecordTransient> levelCallback = new
SormCallback<SRecordTransient>() {
@Override
public QueryResult<SRecordTransient>
doInSession(SSessionJdbc ses) throws DataValidationException {
SQuery<Myrecord> qry = new
SQuery<Myrecord>(Myrecord.meta).eq(Myrecord.attribute, attr);
List<Myrecord> recLst = ses.query(qry);
for(Myrecord rec : recLst) {
if (rec.getVal() > 1000) {
// do something clever within transaction
}
}
SQueryTransient aggQry = new
SQueryTransient(qry).min(Myrecord.level).as("MIN_level");
return new
QueryResult<SRecordTransient>(ses.queryTransient(aggQry));
}
};
return getSormTemplate().execute(new SDataSet(),
levelCallback).exactlyOne().getInt("MIN_level");
}
Regards,
Franck
Le 20/11/2014 11:16, Joachim Durchholz [email protected] [SimpleORM] a
écrit :
>
> Am 20.11.2014 um 09:42 schrieb anthony berglas [email protected]
> [SimpleORM]:
> > P.S. Yes, checked exceptions are a particularly awful idea because they
> > encourage people to gobble exceptions, as do the standard Java
> libraries.
>
> Yup. They should have added discriminated unions (aka sum types aka
> algebraic data types) and structural pattern matching instead. If a
> function that can fail in a way that must be handled returns a
> FileOpenResult: Fail | FileHandle
> then you MUST unpack a FileOpenResult if you want to get at the
> FileHandle (structural pattern matching makes that easy and fun, which
> is why it's important to add as well).
>
> But, ah well, Java isn't going to get that it seems.
>
> > It is interesting that when Java was hot circa 2000 many people believed
> > that checked exceptions made sense.
>
> Heh. I thought it made sense, myself. Under the premise of "well, if
> it's used correctly".
> Except I never found a situation where a checked exception would have
> been useful, except for the kind of abuse you mentioned.
>
> > It is only relatively recently that
> > people started to think differently. There needs to be a compiler option
> > to ignore them, but that will never happen.
>
> Cannot happen, it would break backwards compatibility (your code would
> not compile in an environment where that option isn't set).
> I routinely wrap checked-exception APIs in a thin layer that wraps each
> exception in a RuntimeException (with the original exception embedded,
> for stack traces). It's a bit tedious but not too hard to do, and I tend
> to add some more logging and checking logic at that point anyway.
>
> E.g. my JDBC layer consists of code like this:
>
> static public PreparedStatement prepare (
> Connection connection, String sql)
> {
> PreparedStatement result = null;
> try {
> logger.debug ("Enter: prepare({}, {})", connection, sql);
> try {
> result = connection.prepareStatement (
> sql, ResultSet.TYPE_FORWARD_ONLY);
> } catch (SQLException e) {
> throw new RuntimeException ("Error preparing: " + sql, e);
> }
> } finally {
> logger.debug ("Exit: prepare(...) -> {}", result);
> }
> return result;
> }
>
> The real code is a bit more convoluted, because it adds a parameter for
> result set concurrency, maps the integer codes to a textual
> representation in the log, and deals with multi-line SQL to the extent I
> needed it.
>
> > SimpleOrm never had checked exceptions.
>
> I was talking on the posited assumption that somebody writes their own
> JDBC layer. I didn't intend to state anything about SimpleORM :-)
>
> Regards,
> Jo
>
>
--------------050209070004000200020108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Just as a side note, for thoses using Spring Framework, you can also
have a look at <a class="moz-txt-link-freetext" href="https://launchpad.net/mkorm">https://launchpad.net/mkorm</a><br>
<br>
This project aims at facilitating the use of Simpleorm
(<a class="moz-txt-link-abbreviated" href="http://www.simpleorm.org">www.simpleorm.org</a>) in Springframework, especially by implementing
the Template strategy.<br>
It make it easier to get the try / catch / finally boilerplate done
well, use Spring's annotated transactions, etc.<br>
<br>
So you can write things like this:<br>
<br>
public List<Myrecord> getRecordList(String attr) {<br>
<br>
SQuery<Myrecord> qry = new
SQuery<Myrecord>(Myrecord.meta)<br>
.eq(Myrecord.attribute, attr);<br>
<br>
return getSormTemplate().query(qry);<br>
}<br>
<br>
or more elaborated:<br>
<br>
public int getMinLevel(final String attr) {<br>
<br>
SormCallback<SRecordTransient> levelCallback = new
SormCallback<SRecordTransient>() {<br>
<br>
@Override<br>
public QueryResult<SRecordTransient>
doInSession(SSessionJdbc ses) throws DataValidationException {<br>
<br>
SQuery<Myrecord> qry = new
SQuery<Myrecord>(Myrecord.meta).eq(Myrecord.attribute, attr);<br>
List<Myrecord> recLst = ses.query(qry);<br>
<br>
for(Myrecord rec : recLst) {<br>
if (rec.getVal() > 1000) {<br>
// do something clever within
transaction<br>
}<br>
}<br>
<br>
SQueryTransient aggQry = new
SQueryTransient(qry).min(Myrecord.level).as("MIN_level");<br>
return new
QueryResult<SRecordTransient>(ses.queryTransient(aggQry));<br>
}<br>
};<br>
<br>
return getSormTemplate().execute(new SDataSet(),
levelCallback).exactlyOne().getInt("MIN_level");<br>
}<br>
<br>
<br>
Regards,<br>
Franck<br>
<br>
<br>
<div class="moz-cite-prefix">Le 20/11/2014 11:16, Joachim Durchholz
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [SimpleORM] a écrit :<br>
</div>
<blockquote cite="mid:[email protected]" type="cite"> <span
style="display:none"> </span>
<div id="ygrp-text">
<p>Am 20.11.2014 um 09:42 schrieb anthony berglas
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <br>
[SimpleORM]:<br>
> P.S. Yes, checked exceptions are a particularly awful
idea because they<br>
> encourage people to gobble exceptions, as do the
standard Java libraries.<br>
<br>
Yup. They should have added discriminated unions (aka sum
types aka <br>
algebraic data types) and structural pattern matching
instead. If a <br>
function that can fail in a way that must be handled
returns a<br>
FileOpenResult: Fail | FileHandle<br>
then you MUST unpack a FileOpenResult if you want to get
at the <br>
FileHandle (structural pattern matching makes that easy
and fun, which <br>
is why it's important to add as well).<br>
<br>
But, ah well, Java isn't going to get that it seems.<br>
<br>
> It is interesting that when Java was hot circa 2000
many people believed<br>
> that checked exceptions made sense.<br>
<br>
Heh. I thought it made sense, myself. Under the premise of
"well, if <br>
it's used correctly".<br>
Except I never found a situation where a checked exception
would have <br>
been useful, except for the kind of abuse you mentioned.<br>
<br>
> It is only relatively recently that<br>
> people started to think differently. There needs to
be a compiler option<br>
> to ignore them, but that will never happen.<br>
<br>
Cannot happen, it would break backwards compatibility
(your code would <br>
not compile in an environment where that option isn't
set).<br>
I routinely wrap checked-exception APIs in a thin layer
that wraps each <br>
exception in a RuntimeException (with the original
exception embedded, <br>
for stack traces). It's a bit tedious but not too hard to
do, and I tend <br>
to add some more logging and checking logic at that point
anyway.<br>
<br>
E.g. my JDBC layer consists of code like this:<br>
<br>
static public PreparedStatement prepare (<br>
Connection connection, String sql)<br>
{<br>
PreparedStatement result = null;<br>
try {<br>
logger.debug ("Enter: prepare({}, {})", connection, sql);<br>
try {<br>
result = connection.prepareStatement (<br>
sql, ResultSet.TYPE_FORWARD_ONLY);<br>
} catch (SQLException e) {<br>
throw new RuntimeException ("Error preparing: " + sql, e);<br>
}<br>
} finally {<br>
logger.debug ("Exit: prepare(...) -> {}", result);<br>
}<br>
return result;<br>
}<br>
<br>
The real code is a bit more convoluted, because it adds a
parameter for <br>
result set concurrency, maps the integer codes to a
textual <br>
representation in the log, and deals with multi-line SQL
to the extent I <br>
needed it.<br>
<br>
> SimpleOrm never had checked exceptions.<br>
<br>
I was talking on the posited assumption that somebody
writes their own <br>
JDBC layer. I didn't intend to state anything about
SimpleORM :-)<br>
<br>
Regards,<br>
Jo<br>
<br>
</p>
</div>
<!-- end group email -->
</blockquote>
<br>
<!-- |**|begin egp html banner|**| -->
<br>
<br>
<!-- |**|end egp html banner|**| -->
<div width="1" style="color: white; clear: both;"/>__._,_.___</div>
<div id="fromDMARC" style="clear:both; margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: Franck Routier <[email protected]> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- |**|begin egp html banner|**| -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=7360226/grpspId=1705006905/msgId=2114/stime=1416488084" width="1" height="1"> <br>
<!-- |**|end egp html banner|**| -->
<!-- |**|begin egp html banner|**| -->
<br>
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">
<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/SimpleORM/info;_ylc=X3oDMTJlbWYxZWVhBF9TAzk3MzU5NzE0BGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQxNjQ4ODA4NA--" style="text-decoration: none;">Visit Your Group</a></span>
<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
</ul>
</div>
<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkb3FqNDd1BF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDE2NDg4MDg0" style="float: left;"><img src="http://l.yimg.com/ru/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> • <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> • <a href="mailto:[email protected]?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> • <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>
<!-- |**|end egp html banner|**| -->
</div> <!-- ygrp-msg -->
<br>
<!-- |**|end egp html banner|**| -->
<div style="color: white; clear: both;"/>__,_._,___</div>
</body>
</html>
--------------050209070004000200020108--