jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <sandro.boe...@gmx.de>
Subject Re: Jackrabbit Best Practices/Design Patterns (an attempt)
Date Fri, 09 Nov 2007 20:57:08 GMT
Hi Jukka,

this is an interesting discussion. In general I think you are right that 
JCR is much easier to use than JDBC. But e.g. if one has more than one 
list (like the album having a list of songs and a list of song texts) 
under a node than one has to distinguish the childnodes by
their type or an other criterion (like a node name pattern). In this
case the things are getting somewhat more verbose like this:

public NodeIterator getSongs() throws RepositoryException {
       QueryManager queryManager =
             node.getSession().getWorkspace().getQueryManager();
       String path = node.getPath();
       String searchString = path+"/element(*,"mymusic:Song" )";
       Query query = queryManager.createQuery(searchString, Query.XPATH);
       QueryResult result = query.execute();
       return result.getNodes();
}

public NodeIterator getSongTexts() throws RepositoryException {
       QueryManager queryManager =
             node.getSession().getWorkspace().getQueryManager();
       String path = node.getPath();
       String searchString = path+"/element(*,"mymusic:SongText" )";
       Query query = queryManager.createQuery(searchString, Query.XPATH);
       QueryResult result = query.execute();
       return result.getNodes();
}

Especially in this case a simple
NodeIterator "node.getNodesByType(String nodeTypeName)"
would be very handy. But as it is not available I would personally
favor wrappers for that.

Hoping that expert group folks are reading this:
I'm just curious, was this usecase already considered by the expert
groups and discarded for some reason?

Bye,

Sandro


Jukka Zitting schrieb:
> Hi,
> 
> On Nov 7, 2007 12:38 PM, loproman <loproman@gmail.com> wrote:
>> What are your thoughts? Am I doing anything that might cause issues as
>> things get more complex? I'm new to the concept of JCR, so I'm very
>> interested in learning how I can use it in my code as naturally as possible.
> 
> I wouldn't use your Album and Song classes as they are now, as their
> methods are essentially just wrappers around equivalent JCR methods.
> Such a data access layer is more useful for JDBC, where a method like
> Album.getName() could become:
> 
>        public String getName() throws SQLException {
>            PreparedStatement ps = connection.prepareStatement(
>                "SELECT name FROM albums WHERE albumid=?");
>            try {
>                ps.setString(1, albumid);
>                ResultSet rs = ps.executeQuery();
>                try {
>                    if (rs.next()) {
>                        return rs.getString(1);
>                    } else {
>                        ... // handle error
>                    }
>                } finally {
>                    rs.close();
>                }
>            } finally {
>                ps.close();
>            }
>        }
> 
> No wonder why frameworks like Hibernate are popular...
> 
>> Also, how long should sessions live? With relational databases, best practice
>> is to open and close the connection as quickly as possible. However, it seems
>> like JCR sessions can/should stay open much longer.
> 
> It depends on your application. A standalone client is probably best
> served with a single JCR session (just like a single JDBC connection
> would be a good idea), but a webapp serving multiple independent and
> concurrent requests should probably (unless it wants to leverage the
> transient space for handling unsaved changes) use a session pool or
> start separate sessions for each request.
> 
> BR,
> 
> Jukka Zitting
> 


Mime
View raw message