Language Integrated Query in Java for XML and Relational Database

RIT Scholar Works

Theses

Thesis/Dissertation Collections

2007

Language Integrated Query in Java for XML and

Relational Database

Anurag Naidu

Follow this and additional works at:

http://scholarworks.rit.edu/theses

This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please [email protected].

Recommended Citation

for XML

and

Relational Database

Master's Thesis

Anurag

Naidu

October _26, 2007

Committee

Dr. Axel T _Schreiner, Chair

Dr. Rajendra K _Raj, Reader

Title of thesis or dissertation: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ LANG.VAG.£ \ t-\l~6 RA.,. \::"1> &VE'R'X )~ :SAvA£Oe

Name of author: AN\JR.A.c. NA II> L)

Degree: \'v\ S

c..p

M.PU 1~ ><::"1 t:=N c:...f

Program: CJ) 1v'I..C>\J 1 \;Y$.

zc:.

1 \=-,... c....c:=

College: 6c..c..l S

I understand that I must submit a print copy of my thesis or dissertation to the RIT Archives, per current RIT guidelines for the completion of my degree. I hereby grant to the Rochester Institute of Technology and its agents the non-exclusive license to archive and make accessible my thesis or dissertation in whole or in part in all forms of media in perpetuity. I retain all other ownership rights to the copyright of the thesis or dissertation. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation.

Print Reproduction Permission Granted:

I,

Anurag Naidu

,hereby grant permission to the Rochester Institute Technology to reproduce my print thesis or dissertation in whole or in part. Any reproduction will not be for commercial use or profit.

Signature of Author: _ _ _ _ A_n_u_r_a~g'_N_a_id_u

________

Date: _ _ _ _ _

Print Reproduction Permission Denied:

I, , hereby deny permission to the RIT Library of the Rochester Institute of Technology to reproduce my print thesis or dissertation in whole or in part.

Signature of Author: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Date: _ _ _ _ _ _

Inclusion in the RIT Digital Media Library Electronic Thesis

&

Dissertation (ETD) Archive

I,·

Anurag Naidu

,additionally grant to the Rochester Institute of Technology Digital Media Library (RIT DML) the non-exclusive license to archive and provide electronic access to my thesis or dissertation in whole or in part in all forms of media in perpetuity.

I understand that my work, in addition to its bibliographic record and abstract, will be available to the world-wide community of scholars and researchers through the RIT DML. I retain all other ownership rights to the copyright of the thesis or dissertation. I also retain the right to use in future works (such as

articles or books) all or part of this thesis or dissertation. I am aware that the Rochester Institute of Technology does not require registration of copyright for ETDs.

I hereby certify that, if appropriate, I have obtained and attached written permission statements from the owners of each third party copyrighted matter to be included in my thesis or dissertation. I certify that the version I submitted is the same as that approved by my committee.

The

Undersigned Computer Faculty Approves the Thesis

Language Integrated

Query

in

Java for XML and Relational

Database

Axel T. Schreiner

Dr. Axel T Schreiner,

Chair

Rajendra

K.

Raj

Dr. Raj endra K Raj,

Reader

James M. Kwon

Dr. James M Kwon,

Observer

Thursday, 25 October 2007

XMLand relationaldatabasesarethemostcommonlyuseddata-sources fornumer ous Java-basedenterprise applications. The_ever-growing dependenceofJava-based

applications on these technologies calls for _developing a uniform means of_querying

these data-sourcesin the Java layer such that queries written _{for any}ofthesetech

nologieslooksimilar and areinfactgoverned_bya single grammar. This thesisimple

ments a newbackendsystem_{encapsulatingquerying}capabilities overXMLand JDBC basedrelationaldatabaseswhich would complementthe translationof queries written

usingQuEL [1],alanguageextensiontothe_{Java programming}language. The QuEL

language extensionto Javais part ofanother thesis developed_previously and acts as

the querylanguagefortheback-end implemented in thisthesisforXMLand relational

Contents

1 Introduction 5

2 Core concepts 7

2.1 Hierarchical Data Model

/

Extensible_Markup Language

(XML)

7

2.2 Relational Data Model

/

Relational Database

(SQL)

15

3 Language Integrated _Query

(LINQ)

19

3.1 _XLinqand _DLinq 21

3.1.1 _XLinq 21

3.1.2 _DLinq 21

4 QuEL 22

4.1 QuEL front-end 22

4.2 Object Collections 23

5 QuEL for XML and Relational Database 24

5.1 XML in QuEL 27

5.1.1 Background logic 27

5.1.2 Methodtranslation 28

5.1.3 XML backend design 29

5.2 _{Database query in} QuEL 34

5.2.1 Background logic 34

5.2.2 Method translation 35

5.2.3 SQL backend design 37

6.1 _{QuEL query}translation forXML 43

6.2 _XQueryfor Java 45

6.3 QuEL _query translation for SQL 45

6.3.1 GroupJoin issue 47

7 Conclusion 48

7.1 _Timing 49

8 Limitations 50

8.1 Into 50

8.2 _Timing 51

1

Introduction

Querylanguages are_{programming languages} that are used _typicallyto retrievedata from

databasesor otherinformationstorage mediums. The growingdependenceof major appli

cationson a_varietyofdatabasesystems and othermediums of_storage, likeXML _[2], now

makes it important thatwe are able_{to query}such data-sources in anefficient andconsis

tent manner. These various data storage technologies haveevolved over a_long period of

time and originated from separate companies or special interest groups. What this means

isthateachofthesedifferenttechnologies hasitsown distinct languageswhich areusedto

writequeries for retrieving data.

In this thesis we aim to address the problem of_{heterogeneity in querying different}

data-sources with an aimtointroducea_{syntactically}consistent _querymechanismthat isalmost

independent of the nature ofthe data storage medium that is queried. We demonstrate

the various aspects of_{query preprocessing}that need tobe changedtomake the consistent

query experienceintegrate into Java.

The .NET

community at Microsoft Corporation has made considerable progress in devel

oping Language Integrated Query

(LINQ) [3]

for the _C# and VB languagespecification

in .NET 3.0. This thesis work in conjunction with the thesis "Integrating a Universal

Querying Mechanism in Java"

[1]

is targeted towards _developing a back-end for such a

querylanguage thatwould provide similarbenefits in Javafor _retrievingdataout ofXML

documents and relational databases. One could now write queries _using QuEL _[1], as a

language extensionof_Java,just as one would write SQL

[4]

queries on adatabaseconsole

orXPath

[5]

queriesto operate on aXML document. Apossiblefuture extension ofboth

for a powerful feature in Java that could be used to _{query XML} and relational databases

2

Core

concepts

This chapter takes a closer look at the design and architecture of the two data-sources

that will be the target for QuEL queries for the purpose ofthis thesis. Simple examples

willbe usedtodemonstrate how_writing queriesin SQL

[4]

and XPath

[5]

works_byusing

the _existingAPIs provided in Java and what are the concerns with _writing such queries.

This would _{helpin understanding both} the advantages of_writing queries_{using QuEL}

[1]

as well as the backend designed inthis thesis for XML and relational database.

2.1 Hierarchical Data Model

/

Extensible

Markup

Language

(XML)

XML is a specification for _definingmarkup languages designed to separate data from its

representation. This makes it a_very usefulformat for data representation anddata inter

change between different systems. Though relativelynew in the computer _industry, XML

has become _very popular and is _widely used as an information storage medium and con

figuration data-source insoftware applications.

Consider _beginning with a_verysimple XML document that has information for the staff

in an _{organization,} to see how adocument like thislooks and understand the structure of

such adocument. The document hasfirst _name, last name and phone numberinformation

of each staff member ofthe department and maintainsthem as anXML document as de

<staff>

<person>

<first>Sandy</first>

<last>Ferrara</last>

<phone>55178</phone>

</person>

<person>

<first>Tina</first>

<last>Sturgis</last>

<phone>52529</phone>

</person>

<person male=,true'>

<first>Jason</first>

<last>Harrison</last>

<phone>52529</phone>

</person>

</staff>

Figure 1: Staff XMLdocument as atree

A quick look at the document shows a _striking resemblance to a tree structure which is

rooted at the staff node.

Given this tree-like visualization of the document one could _{imagine querying} this doc

ument _being analogous to_traversing the tree and_pruning out the leavesthat do not pass

the _filtering criteria. One would have to write _{many lines} of code in _{Java using} the W3C

DOM

[6]

toreadthe_{XML document into memory}andthenwrite a visitortocollect nodes

thatpassthe_filteringcriteria oftheuser _queryand constructanewdocumentwith reduced

[image:11.528.135.289.86.332.2]

first last phone

Sandy Ferrers 55

Person mete

'true'

first last phone

Jason Harrison 52!

first last phone

[image:12.528.172.344.55.227.2]

rina Sti#g* 52!

Figure 2: Staff XMLdocument as atree

scenariointhe _{programming domain}to sievethroughXMLdocuments and collect dataof

interest at particular points.

XPath

[5]

is one such_querylanguage tailored to operate _efficientlyover XMLdocuments

to filter out data. XPath queries are _crisp, non-verbose and _extremely powerful tools for

working with XML. Since XML has been constantly gaining importance in the software

industry, a marriageofsome sortbetween XPathand Javawas alwaysalogicalnext step.

The _growing adoption ofthis _technology in the _industrywas cemented further when Sun

introduced XPath APIs in Java 5 (JDK _1.5) for _{querying XML documents,} which made

available thepower of efficient XPath querying from within user-levelJavacode. _XQuery

[7]

is also one such mechanism that can be used to _queryanXML document.

UsingfollowingtwosimpleXMLdocuments, Roomsand_Staff, howa_querycanbewritten

<rooms>

<room room='3021">

<phone>55178<7phone>

</room><!--Sandy-->

<room room='3012'

>

<phone>57905</phone> </room><!-_rina-->

<roomroom='3671'>

< phone >57905</phone> </room>

<room room='3008'>

<phono56084<7phone>

</room><!--_Joanne-->

</rooms>

<staff> <person>

<first>_Sandy</first> <last>Ferrara</last> <phone>55178</phone> </person> <person> <nrst>Tina</hrst> <last>Sturgis</last> <phone>57905</phono </person>

< person >

<first>Joanne</first> <last>Catan</last> <phone >56084</phone> </person>

[image:13.528.96.357.53.183.2]

</staff>

Figure 3: XML document forRooms and Staff

Staff is the same file that we saw above and Rooms is afile that maps the room number

with the phone number associated with that room. A _querying scenario from these two

documentscouldbetosearch across thefiles and match records on phone numbers across

the documents and return staff names with _{the corresponding} room _they occupy. _Fairly

common asthis scenario _maybe, it isnot _exactlya_programming cakewalkto achieve the

desired result.

Assuming that the developer has good knowledge of_XPath, XSLT

[8]

and _HTML, the

codefor_obtainingthe results ofthe _queryacrossthe twoXML fileswould look something

like this in a XSLT file

<?xml version="1.0"

encoding="UTF-8"?>

<xsl:stylesheet version="1.0"

xmlns :_xsl="http://www.w3.org/1999/XSL/Transf orm"

>

<xsl:output method="html" indent="yes" />

<! Read in all the room nodes from the Rooms xml file into a _temporary variable >

<xsl:variable name="data" select="

document('rooms.xml')/rooms" />

<! Construct the html for the page headers etc. > <html>

<head><title>Occupancy page</title></head>

<body>

<table border="l"

align="center"> <tr><td colspan="3"

align="center">

<b>Name and Room occupancy</bx/td></tr>

<xsl:apply-templates select="/staff" />

</table>

</body>

</html>

</xsl:template>

<! Declare the template for _matching the staff and room >

<xsl:template match="

staff">

<! _Apply the template over all the staff nodes >

<xsl:for-each select="

./child: :*"> <xsl:variable name="p" select="

./phone/text

()" _/>

<xsl:variable name="f" select="

./first/text

()" _/>

<! Get all the rooms to test and iterate >

<xsl:for-each select="$data/child: :*">

<xsl:if test="./phone/text() = $p"> <tr>

<td><xsl:value-of select="$f"/></td>

<td><xsl: value-of select="

. /@room"/x/td> </tr>

</xsl:if>

</xsl:for-each>

</xsl:for-each>

</xsl:template>

</xsl:stylesheet>

Figure 4: XSLTto merge Staff and Rooms

The result of the above XSLT on the two XML documents yields the _following HTML

output as can be seenin Figure 5.

Noticethe nested loopsxsl:for-each select with XPath expressionsthat do the trick

along with the presentation HTML code that displays the result. One could debatethe

cumber-NameandRoomoccupancy Sandy 3021 [Tina |3012 |7ma [3671 [Joanne 300S Eileen 3005

,Jason 3005

Christina [3022

Liant [3022

James ;3599

Sam 3596

Figure 5: Result ofXSLT solution

some _{to write,} given howcommon thisscenario is when_workingwith XML documents.

What we have looked at is a non-Javaimplementation ofthe query. Reconsider how the

same canbe achieved _{using Java}andthe Java XPath APIs.

public class XmlSample

{

/**

* Oparam args

*/

public static void main(String[] _args){

DocumentBuilder documentBuilder = null;

Element staff = null;

Element rooms = null;

XPath xpath = null;

String staffXPathExpr = "_/staff/person"

;

String roomXPathExpr =

"/rooms/room";

NodeList outer = null;

NodeList inner = null;

try

{

documentBuilder =DocumentBuilderFactory.newInstance()

.newDocumentBuilderO ;

[image:15.528.196.323.53.207.2]

}

try

{

staff =

documentBuilder.parse(new File("./linq/staff.xml"))

.getDocumentElementO ;

rooms = _{documentBuilder.parse(new} File("

./linq/rooms.xml"))

.getDocumentElement_;

}

catch (SAXException e)

{

e.printStackTraceO;

}

catch (IOException e)

{

e.printStackTraceO ;

}

xpath = _{XPathFactory.newInstanceO}

.newXPathO ;

try

{

outer =

(NodeList) xpath.

evaluate _{(staffXPathExpr, staff,} XPathConstants.NODESET);

inner =

(NodeList) xpath.

evaluate(roomXPathExpr, rooms,XPathConstants.NODESET)_;

}

catch (XPathExpressionException e)

{

e.printStackTrace_;

}

// Match the results in nested _loop // THIS IS THE ACTUAL QUERY LOGIC

int staffCount = _{outer. getLength()}

;

int roomCount = _{inner.getLength()}

;

String roomNum = " "

;

Node roomltem =

null;

for (int i =

0; i < _{staffCount; i++)}

{

Node staffItem = _{outer.item(i)}

;

try

{

roomNum = _{xpath.evaluate("phone/text}()"

, staffItem);

for (int _j =

0; j < _{roomCount; j++)}

{

roomltem = _inner.

item(j);

if(roomNum. equals(xpath.evaluate("phone/text()

"

, roomltem)) )

System.out.println(xpath.evaluate(

"

first/text( )"

, staffItem) + " "+ xpath. evaluate("Oroom", roomltem));

}

// TODO Auto-generated catch block

e.printStackTrace( )_;

}

}

}

}

Figure 6: Javacode forXML merging

The first _thing that catches the eye is the wordiness of the solution and though it solves

the_{problem, maintainability}of repeatedboilerplatecode,mixed withtheactualfunctional

logic will always remain an issue over time. This problem is especially of concernas such

queryies for XML documents are_fairlycommonplace.

Let us elucidate the problems seen so far in _{writing queries,} given the _{existing infras}

tructures and _{technologies,} which would _help explain _why a change in this area is _long

overdue.

Complex codelogic needed for _fairlysimple _querypatterns.

Proficiencyin many technologies like _{XPath, XSLT,} JDK XPathAPIs etchas tobe

combined.

Repetitive boilerplatecodeto supplement the actual _querycode.

The query itselfremainstype unchecked and so _potentially unsafe.

Lackof consistent _{query language for} alldata-sources.

Wewillcomeback to theseobservations when wediscuss thedesign for QuEL andexplain

2.2 Relational Data Model

/

Relational Database

(SQL)

A relational database is adata-store that is based on a relational modelbetween _entities,

a modelthatworkson relational algebra and set _theory Such a relational model was first

proposed_by Edgar Codd

[9]

wherethe word relation refersto atable in the database.

The smallest _building block of a relational database is called an _attribute, which is a

name/value pair. An unordered set of attributes forms a tuple and an unordered set of

such tuples makes _up a _relation, which lends its name to a relational database. How

ever when _dealing with relational databases we use the words _{table, row,} column and

constraints which are equivalent terms that _mapthe mathematicalconcepts on which re

lational databases weredesigned to an actual database implementation.

Someolder databases were also designed on ahierarchical data model like that ofXML.

Mostmoderndatabases havemovedinto a relational model becauseofthegreaterflexibil

ityand advantages thatit provides. Oneofthespecificadvantages with a relational model isa_many-to-many relationsbetweenentities. Oneofthe _{severelylimiting}conditionsfor a

hierarchical modelis that therecan at best be a_one-to-manyrelational _{mapping between}

entities; however, the model cannot accommodate_many-to-many relations.

A simple example of this could be a super-store where products are classified based on

the various sections like _{apparel, grocery,} sports goods etc. The products in the _display

lineare classified under _onlyone_section, however if thereareproducts _{that really}fallinto

morethanone_{section, then the}databasedoesnot provide_anyoptiontolistthesame prod

orderto gather _accountinginformationfrom sectionsforsales statistics. This discussionis

merely toprovide aninsight_{into why}thedatabase_industryhasmovedtowardsarelational

model for its databaseneeds.

Seclionld Name Aisle 101 _Grocery 21 102 Apparel 34 103 Spon 45 101 Foolv/ear 22

Sectionld Produced 101 10 102 12 103IM 14

Productld Name 10 meat 12 flour 14 Nikear

[image:19.528.126.411.162.311.2]

SectionToProduct

Figure 7: Hierarchicalmodel _anomaly

We discussedtheobvious advantage of relationaldatabasesandhowthe databaseindustry

has moved towards a relational _model, focus now on the technologies that one needs to

familiarize oneselfwith in order to be ableto work with relational models. The primary

means of_accessing relational databases is via the Structured _Query Language

(SQL)

[7]

invented _byIBM in the 1970s.

In order to see how SQL is used consider the _following two relational database tables

Staff and Rooms that contain the same data as shown earlier but this time in relational

data model. In orderto perform the same_query as we didfor theXML sample we would

now writea SQLquerythatjoinsthe two Staff andRoomstables onthe _matchingphone

Room F-:-'

302 1 5517* ! 3D'

2 47905

3671 57906 aooe :=

:-Firs Lasl PTvy* Sa-S, =^ 55179

~

= 2-~'Q 5 E>T':*jf toenrae Ga-a~ _'*>'**

- 35- 5-*

Room Staff

Figure8: Room andStaff tables

The_followingSQL_query returns theresult as listed below. The SQL query itself is very

intuitive and simplein structure and does the_job, however database are always coupled

with some applicationforwhich_theyserve asthedata-storeand thus themeasure ofthe

easeof use of adatabaseinthemannerinwhichit may be accessed_bytheapplication it

serves.

SELECT S. FIRST. R ROOM FROMSTAFF AS S JOIH ROOM AS R OH S PHOME R PHONE

First Room

Sandy 3021

Tfa 3012

[image:20.528.140.387.97.167.2]

Joarrae 3008

Figure 9: SQL_queryand result

Javahasthe necessary APIs for writing SQL queries inuser level Java application code.

These APIswereintroduced intothelanguagea_longtimeago andhaveevolved sincethen

[image:20.528.177.350.369.500.2]

Javaprogram again with a large amount ofcode wrapped around the actual query. This

addition _{setup code,} though _{completely functional} and _correct, has similar drawbacks as

outlined for theJava XPath APIs.

public static void main_(String[] args)

{

// Connection setup Connection con =

null;

try

{

Class.forName(

"

org.hsql.jdbcDriver

"

);

con = DriverManager.getConnectionC'localdb"

, "admin", "password");

}

catch (ClassNotFoundException e)

{

e.printStackTraceO ;

}

catch (SQLException e)

{

e.printStackTrace();

}

try

{

PreparedStatement ps = _con

.prepareStatement("SELECT S.FIRST, R.ROOM FROM STAFF AS S JOIN ROOM AS R ON S. PHONE =

R.PHONE;"); ResultSet rs =

ps.executeQueryO ;

while (rs.nextO)

System.out. printIn("NAME: " ₊

rs.getString(O) + " , ROOM:

"

+ _{rs.getlnt(l));}

}

catch (SQLException e)

{

e.printStackTrace(); [image:21.528.71.476.148.524.2]

}

Figure 10: Javacode _using JDBCto accessdatabase

Thepower and speed ofSQL is immense butwith no_type-safety andthe requirementfor

3

Language Integrated

Query

(LINQ)

The previous chapter introducedtwo prominent data-storesthat are_commonly used with

enterprise level applications and the _existing technologies available to _query them. The

areas ofconcern highlighted while _using these technologies points a direction towards an

approach aimed at _alleviating those concerns and _making the entire _query experience as

homogeneous as possible with additional _safety checks that make it consistent with the

high_{level programming} paradigm.

LanguageIntegrated _Query

[10]

is a project at Microsoft that is picking up momentum

inthe _programminglanguage _communityfor its attempt at _bringingin a _queryingsyntax

into mainstream _{programming languages.} The _LINQ mechanism provides the program

mer with a_{way toprogrammatically}organize and extract specificinformationfrom adata

source. It provides a consistent syntax for _writing queries over various data-sources like

object _{collections, XML,} relationaldatabases andeventhird_{party data-sources}as _longas

some ofthe contract requirements are implemented. _Currentlyin_LINQ adatasource can

be a hierarchical _document, like _XML, a _database, like mySQL, theobject _collection, or

any collection that implementsthe Enumerable interface. Given the type of one ofthese

data sources, the user has _{the ability to} extract information from this source _using the

same words in the host language. From this vantage point the programmer is extracting

informationin the same mannerfrom three _entirelydifferent sources.

The .NET platform and C# 3.0 language in particular has incorporated useful language

featuresthatmakes_{seamlesslyincorporating}LINQinto the.NETplatformfeasible. These

include Anonymous _Classes, Extension Methods

[11],

Lambdaexpressions etc. Allthese

re-served words in the language and maps these words into a series ofmethod calls on the

data-source. These method calls are mapped to certain logical operations. For _instance,

the logic ofajoin operation is mapped to a method named join(). This direct mapping

allows for _{many by} products that do not exist in traditional queries performed on data

sources such as databases and hierarchical documents.

Oneofthe biggest resultsofthis _technologyistype_safe

queries, ensuringat compiletime

and not _runtime, that these queries are valid and will not fail. _Ensuring proper _typing

reduces the number of potentialbugs in a programin the same_waya _{strongly typed} lan

guagelikeJavaremoveserrorsthatplague a not so_stronglytypedlanguage likeCor C++.

Consider the _{query below in LINQ} over an _in-memory collection of Employee objects

to find the names ofemployees that areofthe sameage.

var result = _{from el in Employee} from e2 in Employee

where el.ageO ==

e2.age() kk el.nameO != e2.name()

select new {personl =

el.nameO ,person2 =

e2.name()};

Noticehowthe_{query is}simplein itsstructureand no nestedfor loopsare needed as would

berequired in a traditional program. The fromkeywords brings in newdata sources into

the _{queryenvironment, the}where keyworddoes the comparison (like in an if _statement)

andthe select keywordconstructsthereturntypeoftheresult. Thenewobject withthe

names of employeesis not_{previously defined but it is}constructed at runtime and assigned

to a_dynamicallytyped result var.

C#, like Anonymous _Classes, Extension Methods [11], Lambdaexpressions that are not partof_Java, inorder to implement QuEL for XML andrelational databases.

3.1

XLinq

and

DLinq

Theruntimefor_LINQondifferent data-sources differs inwaysthatarespecificto_handling

the respective data-sources though from a user's perspective _LINQ offers the idea of a

consistent _queryexperienceacross _{any data-source backend.}

3.1.1 _XLinq

Theruntime thatprovides_Linqcapabilitiesfor XML _queryingis just an extension of_Linq for data_objects, with some special extension methods that are relevant in the context of

reading XML documents, like theelements0 methodto readthetext value of nodes and

attribO method used to read the text value of an attribute of a node. The rest ofthe

Linqgrammar stays_{the same,} An_{XLinqquery is} thusstructured_exactlythe same_way as a _Linqqueryon collections ofdata objects.

3.1.2 _DLinq

The _Linq grammar _by design resembles the syntax of SQL closely. Thus no additional grammar tokens are needed for _extending the concept of _Linq to databases. The imple mentation for SQL remains the same. Extension methods in the host language backend

corresponding tokeywords inthe querylanguage performthe actions requiredto fulfillthe

4

QuEL

We have lookedat theproblemsidentifiedwith _{query languages}and their integration into

a host high level _{programming language.} We also discussed how the _LINQ project at

Microsoft is _{bringing together query} syntax inside mainstream application _programming

languages like VB.NET and C#. In this chapter we will look at the recently offered po

tential solution _{for query}language support withinthe Javaprogramming language, called

QuEL

[1]

. Theofferedsolutionis afront-endthatconstitutesthenewQuELgrammar and

the translation mechanism that is so far implemented for _performing queries over object

collections.

The QuEL _(QueryEnhanced_Language)mechanismisafront-endpreprocessor which when

given a Javafilewith an embedded _query, written _using the QuELgrammar, will convert

that _{language into syntactically} correct Java_{code, thereby making} queries on Object col

lections less cumbersome and _allowing the programmer to ignore the boiler plate _coding

normallyneeded while_performingthesequeries with thesupported JavaAPIssofar avail

able.

4.1 QuEL front-end

The front-end forQuELasdeveloped inthethesis _"IntegratingaUniversal_QueryingMech

anisminJava"

[1]

consists ofthe completeQuELgrammar andthe translationmechanism

that parses a_query written in QuELandperforms various _{preprocessing}stepsneeded for

it to _mapthe_queryto the appropriateback-end. The steps inthis_{preprocessing involves}

methodtreerepresentation isanabstract_mappingofthe_queryto_{any back-end implemen}

tation. The next _{step is} performed _by aninterpreter that convertsthis abstract _mapping

to a custom _{mapping in} the formof pureJava code.

4.2 Object Collections

So far the interpreterofthe QuEL front-end is configuredto usethe back-endwritten_by

Dr. Axel Schreiner for thepurpose of_queryingon object collectios

[12]

in Java. The Java

codeemitted_bytheinterpretermakes method callsdefined inthisback-endas a successive

method call chain. Thesemethods arethereal operators ontheobject collections on which

theoriginalQuEL _{query iswritten, therebyreturning the}result as _dynamicallycomputed

typedobject collection whichis again usableinuser writtenJavacode. Onecouldimagine

the back-end as the _{proxy for executing}the actual _query andthe _{query language} asjust

syntacticsugar for workdone _bythe back-end.

The same _{LINQ query} from the previous chapter is now _slightly modified and is now

the QuEL _{query imbedded in Java} code within the @@ markers. This query does the ex

act same function as described earlier but now in the Java enviornment _using the QuEL

front-endand object collection back-end that was discussed.

result = _{from edu.rit}

.cs.quel.Person el in Employee

from edu. rit.cs. quel.Person e2 in Employee

where el.ageO ==

e2.age() kk el.nameO != e2.name() select new {personl =

el.nameO ,person2

=

5

QuEL

for XML and Relational Database

Wediscussed in the previouschapter that the QuEL

[1]

mechanism is afront-endprepro

cessor which takes in a Java filewith a QuEL query and translates to pure Java codefor

object collections. The promise ofthis paradigm is however not just to provide a _query

mechanism for data collections but a consistent _querying experience across varied data

sources. Theworkdonein this thesisis aimed at _{providing just} that experience, forwhich

wehavechosenXML andrelationaldatabaseastheotherdatasourcesforwhichthe_query

mechanismcan be extended.

In an earlier chapter on core _concepts, it was discussed _{that writing query} over XML

or a relational database inside of Javacode is cumbersome and involves writing a lot of

code that a _{programmer, for} the most _part, does not like to be bothered about. It can

be debated that the programmer should not be expected to care about all the wrapper

code and focus around the actual logic of query. This is one ofthe basic reasons behind

developing QuEL and _{extending it} to all data-sources like XML and relational database

so that thefocus of_{querying inside} ofJavacomes backto the_{query logic.}

Asdiscussed intheprevious_{chapter, the}grammarforthenewlanguageQuELhas beende

veloped under the thesis _"Integrating aUniversal _Querying Mechanism in Java"

[1]

where

QuEL will be used to write queries on collections inside a Java program that would be

preprocessed _by the QuEL compiler to transform the QuEL part of the code into pure

Javasyntax which could then be compiled_by javac.

The current thesis work utilizes the QuEL grammar for writing queries over DOM and

however some constructs specific to the DOM implementation in Java is not part ofthe

grammar. Thus for the purpose ofthis thesis the back-end for XML assumes the

recog-nistion of these constructs in the grammar so that pure Java code could be build from

QuEL queries for XML data-source. Like in the QuEL paper

[1]

the approach taken to

integrate these queries is a preprocessor based approach, so _{that the extensibility} of the

Java_programminglanguagecanbe easilyproven. This approach alsogivesusthesoftware

engineering advantageof_{maintainability}andindependencefrom subsequent Sun JDK re

leases. Theprocesses of_{incorporating}thenew grammarinto Javawouldthen beto merge

the QuELgrammar and theelements of our new compiler andthe_queryback-endsupport

intothe Java compiler.

Figure 11 provides a high level understanding of the process that converts the special

Java file with QuEL _query through a _{pre-processing} stage into a complete compile able

Javafilewith the right mappings generatedto serve _{the query}functionality.

Theprocess of compilation ofQuELinjected Java code is atwo stageprocess where Java

file is first pre-processed _by the QuEL processor that parses _only the QuEL codewithin

"@@"

markers. The lexer for the preprocessor convertsthe _{query into}aparsetree that is

then mappedto a methodtree. Themethods inthis tree arethemethodsthat correspond

to each keywordofthe _querygrammarlike from, _{where, select,} join etc. The corre

sponding methods are members ofDocumentFragment or _{Queryable interface depending}

on the datasource. The methods form a closed set of operations overthe _resulting type.

Since the operations are closed on the result it makes _{it very} simple to _{apply just} about

Embedded Java Code Preproc&ssedJavaCode DocumentBuilder

docurcentB'jilder=

null; Element staff=

null.-Object q=88fraitr n ]^-ierifg (i -"'n_t'< wheie i

-3005 select new Ir.rc

r.phone! <?8

gruery, elements(

rorir.s.).where<ne*r F.u-: rv,nlen, Elements (1

public Booleanf(E.lern&nr.r) I returnt.getAttribute "room"}. equalfl("3i15")) 1 Preprocessing Puce Java Code / . 1 <-+~\-ylow } Processor ,

\

i 1

A

J

r

L

-. _r4n

? i ?

XML/SOLQuery

[image:29.528.104.419.77.295.2]

Backend Method Tree

Figure 11: QuEL_{preprocessing}process

Lazy evaluation

The designof _anybackend _implementing the requiredinterface actions has to be made a closed set in order to achieve a cascaded evaluationflow whichis also a "lazy" evaluation

mechanism reminiscent in the functional _programming language Haskell. The evaluation chainis triggered_onlywhenresultof_{the query is first}used andnot while each partofthe

queryoperation is constructed. This givesthe _flexibilityof _"adding on"

anyofthe closed

5.1 XML in QuEL

Now cc jr how we canextend the new_{query framework}to beable towrite queries over

XMLdocuments. Also_keepinmindthat theQuELgrammarisgenericforauniform_query

syntaxhowever because_internallytheback-end usesthe_org.w3c.domAPIs inJava, parts

ofthe _queryforXML will haveconstructs that are governed _bythese APIs.

5.1.1 Background logic

TheJavaprogramin Figure 6 isthebaselinethatwe will usetocomparethe improvements

that we claimto achieve with animplementation ofQuEL for XML. Here is allthat now

needs to be written with QuEL in order to read in the Staffand Rooms document and

mergethem togenerate _{the occupancy}list.

final Element staff = _{documentBuilder.par}

se(

Tester. class.getClassLoader0.getResourceAsStream(

"quel/staff.xml")).getDocumentElementO;

final Element rooms = _{documentBuilder.parse(}

Tester. class.getClassLoader( ).getResourceAsStream(

"quel/rooms.xml")) .getDocumentElementO;

result = _{from Element s in elements(staff)}

join Element r in elements_(rooms) on

s.getElementsByTagName

("phone"

) matches

r.getElementsByTagName("phone") into sr select new sr._first, sr.room

Figure 12: QuELqueryfor XML access

before you start the query. The _query then is a _very compact statement that uses the

fromkeyword tointroduce the _Staff source andthe joinkeyword isusedtointroducethe

Rooms source and match on the phone node on both the documents that havethe same

value and merge the results ofthe join filter into a _temporary structure referred _by the

variablesr. Now theselectkeywordisusedchoosethenodes/attributesfromthemerged

document into afinal result whichis aDOM DocumentFragment structure.

5.1.2 Method translation

Inorder to understandtheworkingsbehindthe scenethat makes thewhole _querylookas

simple, less wordy and yet achievethe same _result, we will start _{by looking} at the archi

tectural abstracted view ofthe _processing that is part ofthe _{pre-processing} stage of the

compilation.

Puxe Java cote

Tree it I

Processor

XML backend

Preprocessing to XML

rk

Method sub-trees

[image:31.528.90.437.383.568.2]

r-r-.-.

From Figure 13 it can be seen that a Java file with QuEL code is parsed _by the lexer

and a parsetreeofwith thenodesof_{the query is internally}generated. Note that thepure

Java code part of the file is not scanned in this process and passed though this pipeline

without _any modification. After _{the parsing is done} a mapper(not shown in

figure)

walks

the parse tree and converts the tree _{into something} called a Method tree. This tree is

closer representation of the final Java output that will get generated and has all _typing

related information _alongwith theoriginal_querylambdas andpredicatesthatcan nowbe

worked on _by the interpreterthat converts it to thefinal Java code that can be compiled

with javac.

5.1.3 XML backend design

Inthis section we willdescribetheworkings ofthebackend designed for XML andhowthe

Proxy class in Java is used to add on extension methods to the DocumentFragment class

suchthat the allthe keywords in QuEL correspond tomethods addedto this class_during

runtime.

The extension methods are added to the DocumentFragment _{by defining} an interface

QuELDocumentFragment with some ofthe following methods:

public interface QuELDocumentFragment <T extends Node> extends

DocumentFragment

{

public <K> QuELDocumentFragment select_(Func<K, T> selector);

public <K> QuELDocumentFragment _{groupBy (Func<K}, T> group);

public <K> QuELDocumentFragment orderBy(Func<K, T> group);

Func<Boolean, Node> predicatel, Func<Boolean, Node> predicate2,

Func2<Node, Node, Node>selector)

}

Thefirst_{step in the query}interpretationprocessistocreate aninstanceofthe_Queryclass,

which isthe _entrypoint for_creatinga_proxyoftheDocumentFragment class. This is done

bymakinga callto the_elementsQ methoddefined inthisclass withthe_followingsignature:

public <T extends Node> QuELDocumentFragment elements(Node container)

This methodtakes in anXML document read in as aNodeobject and wraps a

QuELDocumentFragment aroundit. Inadditionitalsoperformsthecheck_p.getNodeType0

== _Node

.ELEMENTJJODE on each node of the input document before it is returned to the

next methodinthe _querycomposition chain. This is important becausewhenaXMLdoc

ument isread into the DOM the nodes constitutesthe _followingsub interfaces likeAttr,

Comment, Document, Entity, Element, Text etc and for the purpose ofthe _query we

will for all practical purposes be concerned _only with the Element node. This _{way the}

elements() isnot_onlyusedtointroduce_{the proxy}wrapperbut alsotoinitializethebasic

filtering for the _querybeing constructed.

Oncethe _{proxy is introduced}allthe QuELkeywordcall methoddefinitions are now visible

and can be invoked at _any point on the resulting object of each method since the return

typeforeach ofthesemethodsisthe sametypeon which themethod was_{invoked, namely}

in the XML case a QuELDocumentFragment class. Here is how a_proxyobject ofthe same

return _{(QuELDocumentFragment)} Proxy.newProxylnstance(

QuELDocumentFragment.class.getClassLoader(), newClass[]

{

QuELDocumentFragment.class, DocumentFragment.class },

new _{QuELDocumentFragmentHandler(this.db, values,}

new Evaluate()

{

public DocumentFragment evalO

{ }

);

It's the_bodyofthe Evaluate interfacethathastheeval₀ methodthatisdistinct foreach

ofthe extension methodsthat have logicspecific tothe action thatneedstobeperformed

bythat method.

Consider a_{query in}QuEL and seethe convertedJavacodeforthe same_usingthebackend

design for XML.

result = _{from Element s in elements(staff)} join Element r in elements(rooms) on

s.getElementsByTagName("phone

"

) matches

r. getElementsByTagName("phone") into sr

where s. getElementsByTagName("last").item(O)

.getTextContent().equals(

" Catan"

)

[image:34.528.77.403.72.236.2]

select new sr._first, sr.room

Figure 14: Another QuEL _{query for XML} access

object(s) thatwould havespecial DOM likeextension methods that would beused to ex

tract node elements and attributes from theDOM. The _query above in QuEL wouldlook

likethe_followingwhen mapped to the Java backend designed in this thesis.

QuELDocumentFragment 1 = _{query. elements}(staff).join(

query.elements(rooms), new Func<String, Element>()

{

public _String f(Element s)

{

return s. getElementsByTagName("phone").item(O)

.getTextContentO;

}

, new FuncjString, Element^)

public _String f(Element r)

{

return r. getElementsByTagName("phone").item(O)

.getTextContentO;

}

, newFunc2jDocumentFragment, Node, Node^()

public DocumentFragment f(Node s, Node sr)

{

return query. combine₍"s", s, "sr", sr) ;

}

).where(new _{FuncjBoolean, Element^/)}

public Boolean f(Element s)

{

return s. getElementsByTagName("last").item(O)

.getTextContentO .equals("Catan");

[image:35.528.65.387.134.430.2]

}

});

Figure 15: Javatranslation for QuEL _queryfor XML

The code generated_{using the} XML backend Queryclass can nowbecompiled _{using javac}

would generatethesame result asthe Javacodethatwe wrotein Core Concepts chapter2.

Although the generated Java code is type safe and _compiles, the _{query itself} can still

failtogeneratethe expected result. The reasonforthat_is, XML isnot schema enforceable

and thus query itselfcannot be type checked for correctness against the XML document

Kayandaims at_{providing type checking}on queries written_{using XPath. This is howwever}

an optional _facility andJavaat this time doesnot support _it, so we ignore this aspect for

the scope ofthis work.

Thus a possible future extension to the QuEL for XML could be to makes the trans

lated queries _completely type safe for documents that adhere to some schema definition.

However for all other XML documents it would be a _{very challenging task to} do achieve

5.2 Database _{query in} QuEL

Now _considering how same _query translation mechanism works for a new data source, in

this case we will lookat themost _commonlyuses database medium, Relational databases.

The_bigchallengeand differencewhile_tacklingthisproblem_is, thatunlike inthe previous

cases for object collections or _XML, the data sourceis on disk and should always remain

on disk _during the entire _query process. This might sound trivial at the moment but it

is animportant situation that needs tobe maintained and whichinfluences the designon

the backend for _SQL, i.e. since allthe information cannot be cached we haveto translate

the _{query into} SQL. We shall discuss that later in this chapter after we have built the

foundation for _querytranslation.

The other important aspect of _{query mapping for} relational databases is that of type

checking. The database tables over which the QuEL _query executes exists on disk and

because the Java compiler has no _way prior knowledge of their _types, some _way needs

to be devised to acquire _typing information about such entities so that we can provide a

type-safe_queryguaranteed to executesuccessfully.

5.2.1 Background logic

Once again reconsider the Java program inFigure 10 as the baseline to compare with for

theimprovementsthatwe claimto achieve with animplementationofQuELforrelational

database. Here is all that now needs to be written with QuEL in order to read in the

Staffand Rooms tables andmerge thembased onthe phone number fieldto generate the

final edu.rit.cs. quel.StaffBean staff = _new

edu.rit.cs.quel.StaffBean(Staff); final edu.rit.cs. quel.RoomBean rooms = _new

edu. rit.cs. quel.RoomBean(Rooms); @@

result = _{from edu.}

rit.cs.quel.Staff Bean s in staff

join edu. rit.cs. quel.RoomBean r in rooms on

s.phone matches r.phone

where r.size > 2000

select new s._first, r.size

Figure 16: QuEL _queryfor database access

Noticethat the_{query is}a_verycompact statement thatuses thefrom keywordtointroduce

the Staff source and the join keyword is used to introduce the Rooms source and match

on the phone column on both the tables that have the value and on the result _apply the

filter condition where the size of the room is greater than 2000. The select keyword is

used to project the columns from the filtered _temporary result into a final result which is

a Queryable<T> _type, where T is the return typeof_{the query} which can be an _internally

generated typeor _anyofthe standardbuilt-intypes.

5.2.2 Method translation

Figure 17 provides an _{understanding}ofthe workings of the translation system for QuEL

for SQL and _{the corresponding} SQL backend.

The process of _converting QuEL for relational database _{query is slightly} different from

the process discussed earlier for XML. The hook for conversion of the QuEL processor

Preprocessing to SQL

Schemelookup

0-Hb

~

Processor

Collections backend

Si

Method sub-trees

S2*!'

Querymethod composition

"fe-Figure 17: SQL_processing

whole translation scheme. The reasonfor thisdifference is for the_following factors:

QuEL queries for relational databases are converted to their SQL equivalent _query

before _they get executed on the database. This approach was taken in order to

leverage the performance that SQL provides for querying _{databases, especially} in

cases when the _scalability of _{the query translation} mechanism is considered then

executing the appropriate SQL query to extract data becomes a _primary concern

for _designing thebackend. Another approach that was considered _initially, involved

frontloading the data in all the tables into data objects called Beans. Once the all

the data in loaded the query could then be run _in-memory on the _beans, like in

the object collectionbackend [12]. Thisapproachworks wellforobjects however the

scale ofdatabase tables is far larger and it cannot be assumed that the system has

enough _memory resources to store all the datain-memory. Also it would not be a

good design approach that stretches the limitsofthe systemresources.

[image:39.528.85.432.54.259.2]

that willhave to beexecuted to retrieve data. The query itself is a_string and thus

cannotbecheckedfor syntacticalandtypecorrectness. Thusthe translation process

should not _only generate the backend code for _{writing the query} as SQL _string, it

should also generate codethat would ensure type_safety ofthe generate query.

5.2.3 SQL backend design

We identified the need for type _checking of the QuEL queries when _{converting to} SQL,

which introduces the open-source object relational _mapping tool SQL2JAVA [14]. The

tool is used to generate classes that will ensure type _{checking for} the queries, and the

query translation mechanism generates code which when complied and run will generate

SQL_query and executethe same onthe concerned databaseand wrapsthe results appro

priately in so that it could be iterated upon _{conveniently in} the user code.

SQL2JAVA

Thetoolis_freelyavailablefor downloadand comes withtheexecutablefortheopen source

HSQLDB

[15]

database. The tool can be configuredto run ant

[16]

scripts that generate

Javaclassesthat_mapto tablesinthe_underlyingrelationaldatabaseschema. The database

schema file should be provided to the tool for it to generate _{these classes,} called Beans.

The beans themselves provide additional _{functionality} like persistence and transactional

capabilities, the capability to execute simple queries such that from a programmer's per

spective the beanscan be treatedas _in-memoryrepresentation oftherealdatabasetables.

However for the purpose of this thesis we shall not use the latter mentioned capabilities

for limitations explainedin the 5.2.3 section.

the _{beans for mapping}the tables into Javaclasses aregenerated before the _{preprocessing}

step and made available to the translation engine. _Only the attributes of the beans will

be used as_{they map to}the columns ofthe tableand in that regard_any other

relational-mappingtool could also be used topregenerate thesebeans. Another alternative to _using

atool could be tohand-writethese beans_byexamining thedatabase schema.

The design for the backend involves the _following Queryable<X> and Evaluate<X> in

terface that serve as the contractfor translation to SQL.

The Evaluate<X> _{interface is} used to hide the _bodyof methodthat chainsthe evaluation

process once itstrigerred.

public interface Evaluate<X>

{

/**

* The method to that computes the _resulting intermediate _query

* and determines if the _query is complete and executes the same * on the database.

*

* return An Iterable result of the _query */

public Iterable<X> _evalO throws _{SQLException;}

}

The Queryable<X>interface declaresthe_publiclyavailable extension methods ofthe

back-end. The translationmechanism calls on thesemethods to build the Java code equivalent

ofa QuEL query.

/**

* type

* _{and maintains} the logic to convert this Expression into

* the SQL _string appropriate time comes, i.e. when the call to * evaluate the result occurs.

* author _Anurag Naidu

*

* param <X>

*/

public interface Queryable<X> extends Iterable<X>

{

/**

* The select contains the columns to project and triggers the * evalution process and this is seen as logical termination of * complete QuEL query.

*

* param select

* _{return An} object of itself so that its a closed operation

*/

public Queryable<X> select(Expression<SqlQuery> select); /**

* The where contains the labmda condition that needs to * _be checked as a _query result filter.

*

* param where * return

*/

public Queryable<X> where(Expression<SqlQuery> where); /**

* The where contains the sources that are introduced into a

* _{QuEL query, namely} the database table names. *

* param from * return

*/

public Queryable<X> from(Expression<SqlQuery> from);

}

The hook intheQuellnterpreterisa subclassthattranslates theQuEL_querytowards the

public interface Expression<T>

{

/**

* _{Function to generate the}

query string. _{The string} generated * so far is passed as input and the result is the same type

* the parts of the _query computer from the extension method

* that defines this Expression class

*

* param Parameter to the function (same as return type)

* return

*/

T f (T param) ;

}

We can now look at the earlier QuEL query on relationaldatabase and compare with the

translated code. The simple _query that brings together the Staff and Rooms tables and

returns all staff member who _occupyrooms with size greater than 200 sq.ft.

final edu. rit.cs. quel.Staff Bean staff = _new

edu.rit.cs.quel.Staff Bean(Staff)_;

final edu. rit.cs.quel.RoomBean rooms = new

edu. rit.cs.quel.RoomBean(Rooms);

@

result = _{from edu. rit}

.cs.quel.Staff Bean s in staff

join edu. rit.cs. quel.RoomBean r in rooms on

s. phone matches r. phone

where r.size > 2000

select new s._first, r.size

Figure 18: QuEL_queryfor database access

The queryaftertranslationismappedto theedu.rit. cs. sql.backend.Querybackend is

Queryable<AN0N1548173586> resultl = _new

edu.rit.cs. sql.backend.Query<AN0N1548173586>(

AN0N1548173586.class, this, null).from(

new _{Expression<SqlQuery>()}

{

public _SqlQuery f(final _SqlQuery current)

{

current.fromClause.append("staff s, ");

return current;

}

}).from(new Expression<SqlQuery>()

{

public _SqlQuery f(final _SqlQuery current)

{

current.fromClause.append("rooms r, "); return _current;

}

}).where(new Expression<SqlQuery>()

{

public _SqlQuery f(final _SqlQuery current)

{

current.partialQueryClause.append("where ");

current.partialQueryClause.appendC'r.size");

current.partialQueryClause.append(">");

current.partialQueryClause.append("200");

return _current;

}

}).select(new Expression<SqlQuery>()

{

public _SqlQuery f(final _SqlQuery current)

{

current.selectClause.append("select ")_;

current. selectClause. append("s.name, r.size,") ; return _current;

}

[image:44.528.76.385.58.480.2]

});

Figure 19: Javatranslation _{for QuEL query} for database

Notice in the converted_{query how} themethod definitionfor the Expression<T> interface

has thecode to writeout itspart ofthe SQL _querystring. When invoked _theycontribute

their part of_{the query to the SqlQuery}object.

joinetc ofEvaluate<X> interfacetriggersthe T f (T param) methodpassedtoitasthe

first _stepwhich cases the chain to first construct the correct SQL _string equivalent ofthe

QuEL query. The methods select or _{groupBy carry} special _meaning as _they execute

the _query on the database _using the internal connection object, in Figure 19 above the

code generatedfor_type-safetychecksisomittedfrom output nowforbrevity, howeverthe

Java code generated also has the _type-safety check code that does not ever get executed

but is merely there as a _{proof, that if}the generated Java file compiles then the query is

6

Comparison

and

Results

This chapter considers a few QuEL queries over XML and relational databases and com

pare the results from the respective backend against the results from a native language

translation ofthesame query. As discussed in the backend design for relational _database,

the QuEL _{query is} converted to the SQL equivalent and one ofthe measureof success for

the backend is the comparison between the backend generated _query and original QuEL

queryhand-written as SQL.

6.1 QuEL _{query translation} for XML

Assume that we have the same _Staff and Rooms XML documents from Figure 3 and we

wanttomerge thetwo documentsonthe_matchingphonenumbers andcreate a new

docu-ument _using the name and room values after _groupingthem based on room numbers and

alphabetically reverse _sorting the names within each group. The QuEL _query to do the

same would likethe following:

result = _{from s in elements}(staff) join r in elements_(rooms) on

s.getElementsByTagName(phone) .item(O).getTextContent() matches

r.getElementsByTagName(phone) .item(O).getTextContent0 into sr

select new

{

s.getElementsByTagName(f irst).item(O),

room = _{r.getAttribute(foom)}

group by r.getAttribute(foom)

Figure 20: Quel _queryforXML

The_{translated query}returns the

following

resultwhichmatcheswiththesame_querywrit

ten_{usingJava APIs for XML processing}

involvingmanymorelinesofcodethan the QuEL

query.

Group groupedBy='3012'

first room='3012'

'Tina'

Group groupedBy='3599'

first room=3599

'James'

Group groupedBy= '₃₀₀₅'

first room='3005'

'Eileen'

first room='3005'

'Jason'

Group groupedBy='3022'

first room='3022'

'Christina'

first room='3022' 'Liane'

Figure 21: _{XML query}result

Wewill _skip the translated Java code_{using XML} backend fromthistext dueto the shere

size of_{the code,} however it is_interestingto notehow thisconciseQuEL_querytogenerate

thisresults expands almost ten times itssize when convertedto pureJava using theXML

backend and when compared with code written _{using only the} available Java APIs for

XML is roughlytwentytimesthelengthoftheactual QuELquery. This_onlygoestoshow

interactingwith XML documents.

6.2

XQuery

for Java

There are a some _XQuery

[7]

implementations that are available for use in Java as API

calls. Oneofthem isOJXQI

[17]

proposed_byOracle

[4]

designedonthelinesofJDBC

[18]

with similar APIs. OJXQI could be used to _{query XML documents by preparing} a

PreparedXQueryobject and _constructingan _XQueryqueries with it.

OJXQI _being similar to JDBC in _Java, has some advantages and similar disadvantages

discussed in chapter 2 on XML which this thesis attempts to alleviate. However OJXQI

also allows support for SQL queries on documents through a _{sqlquery function.} These

features _bring it close the syntax of _QuEL, however _{using OJXQI} still involves writing

boilerplate _setup codejust like in JDBC.

6.3 _{QuEL query} translation for SQL

ConsideraQuEL_querytoretrievedata froma relational_database,inthiscaseHSQLDB _[15],

that has the tables that we will query. Assume that we have the _Staff and Rooms tables

fromFigure 8in our database and wejoinon thephone column andthen filterout rooms

on the condition that _they are greater than 2020 sq.ft. and numbered above 2000 with

theresults grouped_byromms with same size. A SQL querytodothesame wouldlook_like,

select s.*, r.size from rooms r

inner join staff s on s.phone = _r.phone

and r.size > 2020

order _by r.size

The same _querywritten in QuEL would then look _like,

result = _from

sql2java.linq.database. RoomsBean r in rooms

join sql2Java.linq. database.Staff Bean s in staff on r.phone matches s. phone

where r.size > 2020

where r.number > 2000

orderby sr.size

select new _sr.name, sr._number, r.size

@@ . . .

The SQL backend converts _{this query into} the _{following SQL,}

select _s.name, s.phone, r.size from rooms r

join staff s on s. phone = _{r. phone}

where r. number > 2000 and r.size > 2020

order _by r.size

The result of_executingthe QuEL _{query is} the same as _executingour first SQL _query,

name=JasonMorrison phone=4010 size=2030

6.3.1 _{GroupJoin issue}

OneofthelimitationsoftheQuELtranslationmechanism for SQL iswiththe into clause

withthe joinand_groupbyclauses. The_followingQuEL_queryconvertsto theappropriate

SQL however_{wrapping the ResultSet into the} correct return typeclass fails.

result = _from

sql2Java.linq.database. RoomsBean r in rooms

join sql2java. linq.database. Staff Bean s in staff

on r.phone matches s. phone into sr

select new _sr, r.number

The translated SQL appears likethe

following

select sr.*, r. number

from (

select s.name, r.*

from rooms r

inner join staff s on s. phone =

r. phone

) sr,

rooms r

This _query executes on the database however the because the select clause specifies the

variable sr as one ofthe return types the QuEL mapper

[1]

creates the return type class

for the whole _query with an instance of Staf fBean wrapped in a Iterablelmpl. This is

however insufficientforthe purpose ofSQLsince use of srin theselect clauseisequivalent

to selecting all the columns of the table _Staff and Rooms. This makes the return type

7

Conclusion

Reconsidering

the problem areasthat we identifiedearlier with _writinga_queryover XML

using XPathandDOMAPIs orover a relational database_{using SQL in Java}andcompar

ing how the QuEL _wayof_querying onXML andSQL backend solves theseproblems.

Complex codelogic neededfor_fairlysimple _querypatterns

A _queryfor_{performing the} same operation _{is simpler,} cleaner and more intuitive.

Proficiency in many technologies like_{XPath, XSLT,} JDK XPath APIsis needed. Theprogrammer _onlyneeds to learn QuELforthe most partfor writing queries over

any of the supported data sources.

Repetitiveboilerplate codeto supplement the actual_querycode.

No boilerplate code is written _by the programmer. The backendfor the respective

data source _technologywill auto generate all boilerplate code and_{keep the query} logic clean.

The query itselfremainstype unchecked and so _potentially unsafe.

The query is not checkedfor type _{safety by} the backend. Since the backendgenerates pure Java code that is compiles, thus the queries are themselves are assured _ofbeing

type checked otherwise the code generated by the backendwould not have compiled.

Lack of consistent _{query language for} all data-sources.

QuEL grammardoes not change significantlywith the data-source itoperates on and

7.1

Timing

T