persistence model philosophy

[JonathanKohl]

Background information: I've worked in data mining, reporting,
business intelligence, and I've been building or testing web
applications for quite a few years. One of the things that has been a
constant source of problems is the standard relational database model.
A few years ago while writing a test tool in Lisp while simultaneously
working with XQuery, I had an epiphany about data and how we manage it
in applications. I could do so much with XQuery without structuring
data that much, and from multiple sources. In Lisp, you have lists of
data stored in memory, and car or cdr or whatever your choice is to
find unions and intersections. I started to question why we always
reach for a relational database when we look at persistence. I know
longer assume I need to use that as a persistence model, and in many
cases on high volume systems, the O/R M, database, and interactions
are a large source of problems. I've found I'm not alone in this
thinking, as the nosql movement has gained momentum.
http://www.infoq.com/articles/nosql-in-the-enterprise

On the Session Tester project, a relational database feels like
overkill. XML or text files are human readable, auditable, can be
submitted to regulators, and are a natural extension of basics of SBTM
as defined by the Bach brothers in their original document coining the
term. It flows naturally for testers who are used to documentation
using text editors or publishing software. Furthermore, it adds more
to the install footprint. A small lightweight testing tool is often
something that strict IT departments will allow to be installed as a
specialist tool. When a database is involved, there are often more
rules surrounding what they can and can't install. XML for persistence
and XQuery seems like a natural fit, and this project seems ideally
suited for exploring this.

When it comes to group management of sessions/charters, I can see
problems arising with file locking when multiple users want to view a
session file, but I think trying to solve that with a database is
still overkill. One of the cool things about a project like this is we
get to try out technology that we may not get to work with in our day
jobs, so I like to encourage non-traditional solutions that help us
solve problems, while we learn something new at the same time. We can
always shift and change where a proprietary project has more pressures
for time and timing.

Therefore, for Session Tester, I would prefer we explore XML/XQuery
for persistence, and see if it works or not. If it fails, I am open to
other solutions, including relational databases. However, I want to
try this out. if we do it well, maybe we could pitch for one or more
of us to participate in a conference like this: http://nosqleurope.com/

I have used saxon for XQuery: http://saxon.sourceforge.net/ and I
tried out the oXygen editor to learn and try out XQuery basics. Basic
info: http://en.wikipedia.org/wiki/XQuery


-Jonathan


--
Subscription settings: http://groups.google.com/group/session-tester-development/subscribe?hl=en

[Jared Quinert]

Sounds good.  When we start looking at shared repositories, we need to make sure we're testing concurrency thoroughly.  Are you aware of any issues?

 

Jared

[JonathanKohl]

I haven't modeled it beyond a single team yet, so that needs to be
explored further.

-Jonathan

On Apr 21, 5:55 pm, Jared Quinert <xflib...@gmail.com> wrote:
> Sounds good.  When we start looking at shared repositories, we need to make
> sure we're testing concurrency thoroughly.  Are you aware of any issues?
>
> Jared
>

> >http://groups.google.com/group/session-tester-development/subscribe?h...