You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Ryan Shelley <12...@gmail.com> on 2008/02/25 00:02:49 UTC
Save Generated WHERE Clause
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 create
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
Re: Save Generated WHERE Clause
Posted by Nathan Maves <na...@gmail.com>.
Not being a serializing expert would you have to worry about that Java
version of the client that is using this serialized object?
On Mon, Feb 25, 2008 at 1:25 PM, Ryan Shelley <12...@gmail.com>
wrote:
> 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 built
> SQL statement.
>
> -Ryan
>
>
> On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <na...@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
> > storing 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 <12...@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 the
> > > Example classes, however, if they want to save that filter for later (since
> > > 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 <je...@gmail.com>
> > > wrote:
> > >
> > > > I assume you are talking about the Abator example classes. But this
> > > > isn'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 custom
> > > > 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 the 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
> > > > > create 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
> > > > >
> > > >
> > > >
> > >
> >
>
Re: Save Generated WHERE Clause
Posted by Larry Meadors <la...@gmail.com>.
On Mon, Feb 25, 2008 at 5:08 PM, Ryan Shelley <12...@gmail.com> wrote:
> What was the nightmare you encountered with serializing the Example class to
> XML and storing that?
It was just extremely fragile - any change to the database structure
or queries broke all of the saved reports.
Larry
Re: Save Generated WHERE Clause
Posted by Ryan Shelley <12...@gmail.com>.
I seriously don't want to have to rebuild the filter logic in my code and
database if I can avoid it. I've done it in the past, and that took more
time to get right than the rest of the tool that used it.
What was the nightmare you encountered with serializing the Example class to
XML and storing that?
-Ryan
On Mon, Feb 25, 2008 at 3:03 PM, Larry Meadors <la...@gmail.com>
wrote:
> 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 <12...@gmail.com>
> wrote:
> > Well, what I see more commonly is that a developer does work with MySQL
> and
> > 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
> need
> > 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
> changes,
> > in which case, the Example class won't match any longer, and
> unserializing
> > 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
> use
> > to unserialize it into, but still, the table schema won't match.
> >
> > -Ryan
> >
> >
> >
> > On Mon, Feb 25, 2008 at 1:16 PM, Kezerashvili, Denis
> > <De...@gs.com> wrote:
> > >
> > >
> > > I've been involved in two migrations in two different companies. One
> from
> > Oracle to Sybase, another one from Sybase to DB2. DB switch does happen
> in
> > 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
> hear
> > that argument a lot (don't use feature X….you might want to switch
> databases
> > 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
> built
> > 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
> storing
> > 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
> the
> > Example classes, however, if they want to save that filter for later
> (since
> > 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 <je...@gmail.com>
> > wrote:
> > >
> > >
> > > I assume you are talking about the Abator example classes. But this
> isn'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
> custom
> > 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
> the
> > 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 <12...@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
> create
> > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
Re: Save Generated WHERE Clause
Posted by Larry Meadors <la...@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 <12...@gmail.com> wrote:
> Well, what I see more commonly is that a developer does work with MySQL and
> 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 need
> 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 changes,
> in which case, the Example class won't match any longer, and unserializing
> 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 use
> to unserialize it into, but still, the table schema won't match.
>
> -Ryan
>
>
>
> On Mon, Feb 25, 2008 at 1:16 PM, Kezerashvili, Denis
> <De...@gs.com> wrote:
> >
> >
> > I've been involved in two migrations in two different companies. One from
> Oracle to Sybase, another one from Sybase to DB2. DB switch does happen in
> 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 hear
> that argument a lot (don't use feature X….you might want to switch databases
> 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 built
> SQL statement.
> >
> > -Ryan
> >
> >
> > On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <na...@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 storing
> 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 <12...@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 the
> Example classes, however, if they want to save that filter for later (since
> 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 <je...@gmail.com>
> wrote:
> >
> >
> > I assume you are talking about the Abator example classes. But this isn'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 custom
> 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 the
> 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 <12...@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 create
> 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
> >
> >
> >
> >
> >
> >
> >
> >
>
>
Re: Save Generated WHERE Clause
Posted by Ryan Shelley <12...@gmail.com>.
Well, what I see more commonly is that a developer does work with MySQL and
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 need
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 changes,
in which case, the Example class won't match any longer, and unserializing
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 use
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 from
> Oracle to Sybase, another one from Sybase to DB2. DB switch does happen in
> 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
> hear that argument a lot (don't use feature X….you might want to switch
> databases 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 built
> SQL statement.
>
> -Ryan
>
> On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <na...@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 storing
> 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 <12...@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 the
> Example classes, however, if they want to save that filter for later (since
> 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 <je...@gmail.com>
> wrote:
>
> I assume you are talking about the Abator example classes. But this isn'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 custom
> 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 the
> 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 <12...@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 create
> 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
>
>
>
>
>
>
>
>
>
>
RE: Save Generated WHERE Clause
Posted by "Kezerashvili, Denis" <De...@gs.com>.
I've been involved in two migrations in two different companies. One
from Oracle to Sybase, another one from Sybase to DB2. DB switch does
happen in 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 hear that argument a lot (don't use feature X....you might
want to switch databases 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 built SQL statement.
-Ryan
On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves
<na...@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 storing 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
<12...@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 the Example classes, however, if they want to save that
filter for later (since 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
<je...@gmail.com> wrote:
I assume you are talking about the Abator example classes. But
this isn'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 custom 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 the 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
<12...@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 create 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
RE: Save Generated WHERE Clause
Posted by Jason Kratz <ja...@firm58.com>.
Of course you'd also have to ask how likely is a DB vendor switch? I hear
that argument a lot (don't use feature X..you might want to switch databases
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 built SQL
statement.
-Ryan
On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <na...@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 storing
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 <12...@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 the Example
classes, however, if they want to save that filter for later (since 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 <je...@gmail.com> wrote:
I assume you are talking about the Abator example classes. But this isn'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 custom
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 the
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 <12...@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 create
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
Re: Save Generated WHERE Clause
Posted by Nathan Maves <na...@gmail.com>.
Very true Jason.
The way I see it changing 10% of my code which may be vendor specific is
cool with me. Storing sql for thousands of users and then having to change
that.... Think about the difference.
Nathan
On Mon, Feb 25, 2008 at 1:28 PM, Jason Kratz <ja...@firm58.com> wrote:
> Of course you'd also have to ask how likely is a DB vendor switch? I
> hear that argument a lot (don't use feature X….you might want to switch
> databases 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 built
> SQL statement.
>
> -Ryan
>
> On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <na...@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 storing
> 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 <12...@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 the
> Example classes, however, if they want to save that filter for later (since
> 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 <je...@gmail.com>
> wrote:
>
> I assume you are talking about the Abator example classes. But this isn'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 custom
> 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 the
> 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 <12...@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 create
> 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
>
>
>
>
>
>
>
>
>
Re: Save Generated WHERE Clause
Posted by Ryan Shelley <12...@gmail.com>.
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 built SQL
statement.
-Ryan
On Mon, Feb 25, 2008 at 11:13 AM, Nathan Maves <na...@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 storing
> 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 <12...@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 the
> > Example classes, however, if they want to save that filter for later (since
> > 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 <je...@gmail.com>
> > wrote:
> >
> > > I assume you are talking about the Abator example classes. But this
> > > isn'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 custom
> > > 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 the
> > > 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 <12...@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
> > > > create 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
> > > >
> > >
> > >
> >
>
Re: Save Generated WHERE Clause
Posted by Nathan Maves <na...@gmail.com>.
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 storing
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 <12...@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 the
> Example classes, however, if they want to save that filter for later (since
> 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 <je...@gmail.com>
> wrote:
>
> > I assume you are talking about the Abator example classes. But this
> > isn'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 custom
> > 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 the
> > 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 <12...@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 create
> > > 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
> > >
> >
> >
>
Re: Save Generated WHERE Clause
Posted by Ryan Shelley <12...@gmail.com>.
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 the Example
classes, however, if they want to save that filter for later (since 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 <je...@gmail.com> wrote:
> I assume you are talking about the Abator example classes. But this isn'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 custom
> 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 the
> 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 <12...@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 create
> > 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
> >
>
>
Re: Save Generated WHERE Clause
Posted by Jeff Butler <je...@gmail.com>.
I assume you are talking about the Abator example classes. But this isn'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 custom
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 the
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 <12...@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 create
> 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
>