Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (athena.apache.org: domain of larry.meadors@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LMCgVshx0DDlUrSl//s50hxW1UK7L64yGKWN3oX5em2rz4hIBDICD8PD0mHgF1VSkO5VEOPMJ9cQ2DRBCiqhLOfVJ0/pFgOb6lTNJkkgkWgffRvoi+DSHTR9U5uh+IHbeH1kOLJZjfvudbMgi7gqH59lKp7dilWEotfJKC8BVoE=
Message-ID: <a10a823c0802251503s202a18a8s8ba33804615a1d99@mail.gmail.com>
Date: Mon, 25 Feb 2008 16:03:18 -0700
From: "Larry Meadors" <larry.meadors@gmail.com>
Reply-To: larry.meadors@gmail.com
To: user-java@ibatis.apache.org
Subject: Re: Save Generated WHERE Clause
In-Reply-To: <748cba5d0802251431g1eae15c9n2521e9baf4a9015a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <748cba5d0802241502l50dd7d69pfe496be1d63f7880@mail.gmail.com>
	 <c593b8750802250849l178d3505p329f0d9bb630f95b@mail.gmail.com>
	 <748cba5d0802251027vee0c71exffad35f42df87ce2@mail.gmail.com>
	 <2f55db670802251113t5cd22aa0r6563a56add2c5b5c@mail.gmail.com>
	 <748cba5d0802251225s61e603c5w3a2e469cbd3383bb@mail.gmail.com>
	 <9A1FB294C6BAB244BF5EC1A90DD5807004182341@gsmbcdp25es.firmwide.corp.gs.com>
	 <748cba5d0802251431g1eae15c9n2521e9baf4a9015a@mail.gmail.com>

I have done this a few ways - one was serializing the beans used to
generate the report as xml files - a freaking nightmare. Don't do
that.

The other way was to treat the query as any other object you want to
save - do you serialize products or orders? No, you save the
attributes that are important to you in fields and deal with changes
to the report the same way you deal with changes to the application.

Database changes impact both the application and the reports the same
way, so why treat them differently?

So, here's my $0.02 worth of advice: Don't try to cheat it in, treat
it like any other application that relies on your database, because
that is what it is.

Larry


On Mon, Feb 25, 2008 at 3:31 PM, Ryan Shelley <12gaugemedia@gmail.com> wrot=
e:
> Well, what I see more commonly is that a developer does work with MySQL a=
nd
> then deploys to another architecture for QA and Prod.
>
> Ultimately, there won't be more than a hundred serialized Example class
> objects in my table at a time.  Users will create them for a specific nee=
d
> within a given time frame, and after that time frame has passed, they can=
 be
> safely removed.  Therefore, I won't have to worry much about changing
> architectures, and if the architecture does change, I won't need to
> re-architect the serialized Example class, just make sure the dynamic SQL=
 is
> generated properly (assuming datatypes are consistent).
>
> The only issue I COULD have, is if the data structure of the table change=
s,
> in which case, the Example class won't match any longer, and unserializin=
g
> the stored objects would throw an exception.  I suppose I could use
> "domainObjectName" on the table to define a class name with a version
> number, and then inspect the serialized XML to determine which class to u=
se
> to unserialize it into, but still, the table schema won't match.
>
> -Ryan
>
>
>
> On Mon, Feb 25, 2008 at 1:16 PM, Kezerashvili, Denis
> <Denis.Kezerashvili@gs.com> wrote:
> >
> >
> > I've been involved in two migrations in two different companies. One fr=
om
> Oracle to Sybase, another one from Sybase to DB2. DB switch does happen i=
n
> real life in real companies.
> >
> >
> > ________________________________
>  From: Jason Kratz [mailto:jason.kratz@firm58.com]
> > Sent: Monday, February 25, 2008 3:29 PM
> >
> > To: user-java@ibatis.apache.org
> > Subject: RE: Save Generated WHERE Clause
> >
> >
> >
> >
> >
> >
> > Of course you'd also have to ask how likely is a DB vendor switch?  I h=
ear
> that argument a lot (don't use feature X=85.you might want to switch data=
bases
> some day!) and have yet to hear of many cases where a DB vendor switch
> actually happened.
> >
> >
> >
> > Jason
> >
> >
> >
> >
> > From: Ryan Shelley [mailto:12gaugemedia@gmail.com]
> > Sent: Monday, February 25, 2008 2:26 PM
> > To: user-java@ibatis.apache.org
> > Subject: Re: Save Generated WHERE Clause
> >
> >
> >
> >
> >
> >
> > Well, if I serialize the Example class, then changing the db vendor isn=
't
> an issue, but it's a very good point if I decided to save the actual buil=
t
> SQL statement.
> >
> > -Ryan
> >
> >
> > On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <nathan.maves@gmail.com>
> wrote:
> >
> > not to rain on the parade but I think the idea of storing sql would be =
a
> bad thing.  Just imagine the amount of work in the event of a DB vendor
> switch.... ouch
> >
> > I would say think outside the box and find a different solution to stor=
ing
> the save criteria.  Even the idea of serializing the Java class gives me
> chills.
> >
> >
> >
> >
> >
> >
> > On Mon, Feb 25, 2008 at 11:27 AM, Ryan Shelley <12gaugemedia@gmail.com>
> wrote:
> >
> > You're correct about the Abator example class.  The idea is that there
> will be records in the database that my users want to extract based upon
> their own criteria.  I can allow them to filter dynamically based upon th=
e
> Example classes, however, if they want to save that filter for later (sin=
ce
> they can be complex), I'd like to store it in the database.  Since the
> values of the filter don't change, I don't see a problem with saving the
> Example class.  I did figure out that I could serialize the Example class
> and store that in the database, and unserialize it when I want to use it,=
 so
> that is probably the best option for now.
> >
> >
> >
> >
> >
> >
> > On Mon, Feb 25, 2008 at 8:49 AM, Jeff Butler <jeffgbutler@gmail.com>
> wrote:
> >
> >
> > I assume you are talking about the Abator example classes.  But this is=
n't
> exactly an Abator issue.
> >
> >
> >
> >
> >
> > iBATIS dynamic SQL is resolved at run time based on the values in the
> parameter object - so you'd need to capture the SQL after the resolution
> step and save it somewhere.  You could probably do this by tinkering with
> iBATIS internals, but the easiest way to do it would be to create a custo=
m
> logger and grab the SQL from the log.
> >
> >
> >
> >
> >
> > Another alternative would be to serialize the example class as you've
> suggested - but this doesn't save the SQL, it only saves the values in th=
e
> example class - which would generate the same SQL on reuse.
> >
> >
> >
> >
> >
> > Is this some kind of a user preference or user history thing?
> >
> >
> >
> >
> >
> > Jeff Butler
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Feb 24, 2008 at 4:02 PM, Ryan Shelley <12gaugemedia@gmail.com>
> wrote:
> >
> > I'd like to be able to save the WHERE clause generated by the Example
> classes in a database.  The purpose is so that I can allow users to creat=
e
> custom filters which distill down to SQL criteria, and then save them for
> re-use later.  I'm curious if anyone else has had a similar requirement, =
and
> whether they attempted to serialize the Example object to XML, or if they
> attempted to capture the generated SQL in another SQL statement.  Any
> thoughts?  Thanks!
> >
> > -Ryan
> >
> >
> >
> >
> >
> >
> >
> >
>
>