Problems Of String Based Query Languages
Let's look how a query can be expressed against the Car
class in some of the object querying languages:
OQL
String oql = "select *
from pilot in AllPilots where pilot.points < 100";
OQLQuery query = new
OQLQuery(oql);
Object pilots =
query.execute();
JDOQL
Query query =
persistenceManager.newQuery(Pilot.class, "points < 100");
Collection pilots =
(Collection)query.execute();
db4o SODA, using C#
Query query =
database.Query();
query.Constrain(typeof(Pilot));
query.Descend("points").Constrain(100).Smaller();
IList pilots =
query.Execute();
As you can see, query parameters ("points") and constraints
("<100") are expressed as strings, which results in the following problems:
- Modern
development environments do not check embedded strings for syntactic and
semantic correctness. A small typo in a query (for example 10 instead of
100) will be very difficult trace, moreover it can pass unnoticed to a
production version.
- Embedded
strings are not affected by refactoring tools. As the application evolves
and the changes are made to the field variables, the string-based queries
will become obsolete and will need to be changed by hand.
- String
queries address fields directly instead of using publicly accessible
methods/attributes, breaking encapsulation principle.
- Embedded
strings can be on the way of modern agile techniques, which encourage
constant refactoring. Since string queries are difficult to refactor and
maintain they will delay a decision to refactor and result in a
lower-quality code.
- Working
with a string query language inside an OO language requires a developer to
learn both and switch between them in the development cycle.
- Reusability
support of OO languages (method calls, polymorphism, overriding) are not
accessible to string-based queries.
- Embedded
strings can be subject to injection attacks.