struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Jaffa" <jaffa...@hotmail.com>
Subject Re: [OT] What do you do with your SQL?
Date Fri, 26 Jul 2002 21:13:24 GMT
I am currently doing this right now.
I set in an XML file all data about the in and out parameters for a stored
procedure.
Including package name and stored procudure name, and all returned row
names.
This allows me to get rid of the serveral pitfalls.

Spec, when u return a row from a db and dont need it yet you do not need to
have it in the xml,
when u need it add it to the xml and u are done.

Works rather well.  I also use an EJB to gather all the data from the DB and
return a
formBean back filled with data.  And if i need multiple rows i have it
return an ArrayList.
(though when i am going to change this to return a lazyArrayList when i go
1.1)




Daniel Jaffa
----- Original Message -----
From: "Yang, Pedro" <Pedro.Yang@schwab.com>
To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
Sent: Friday, July 26, 2002 4:57 PM
Subject: RE: [OT] What do you do with your SQL?


> Where you actually place your SQL logic (statements) sometimes has a lot
to
> do:
> (1) what DBMS your system is using (MS SQL Server, Oracle, to name a few);
> (2) what DB development resource and knowledge your team has.
>
> If a right DBMS is used, with the sufficient DB knowledge, the stored
> procedures can be a good solution.
> The common pitfall with this approach is to hardcode the SP name and
> parameters in the Java codes.  To avoid this problem, you can store the
> values in a xml file.
>
> -----Original Message-----
> From: Struts Newsgroup [mailto:struts@basebeans.com]
> Sent: Friday, July 26, 2002 1:40 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: [OT] What do you do with your SQL?
>
>
> Subject: Re: [OT] What do you do with your SQL?
> From: Vic C <vic@basebeans.com>
>  ===
> Think about it the other way, make your application information driven.
>
> For example:
> Select * from rules where client = a
>
> and client_id or org_id to every table.
>
> Think about it for a bit with a SQL expert (SQL Expert == someone with 7
> years or more of SQL deployment).
> Vic
>
>
>
>
> Nelson, Tracy (ETW) wrote:
> > I once prototyped a system where I  kept all the SQL statements in the
> > database itself.  The original intent was to take the statements and
> > actually compile them into stored procedures, but the project was
dropped
> > before that part was finished.
> >
> > Cheers!
> > -- Tracy Nelson
> >
> > -----Original Message-----
> > From: Assenza, Chris [mailto:cassenza@Accessdc.com]
> > Sent: Friday, July 26, 2002 13:17
> > To: 'Struts Users Mailing List'
> > Subject: [OT] What do you do with your SQL?
> >
> >
> > Hi all,
> >
> > Been a while since I last wrote, but I've been lurking to observe all
the
> > crazy antics. :)  Anyway, I've got a question of an [ot] nature that I
> > believe you folks will have an answer for.
> >
> > Our application is highly data-driven and as such a lot of our "business
> > logic" is written to build SQL statements and handle query results.
> Pretty
> > typical stuff.  Using Struts we pass data objects to a stateless session
> EJB
> > where all the SQL is directly embedded into the java source one way or
> > another.
> >
> > We're currently converting this custom app into a product. As such, we
> need
> > to be able to have easily modifiable SQL statements without requiring
> > recompilation of code.  For example, if client A decides to buy our app
> and
> > they have xyz infrastructure or business rules, we need to be able to
> easily
> > modify sql, hints and the like while also supporting the client-specific
> > sql, hints, etc. of client B.
> >
> > A lot of our SQL is built on the fly so using properties files may be a
> > little cumbersome, though certainly not beyond our means.  I have other
> > ideas floating around, but I'd rather just hear yours - any suggestions?
> >
> > Thanks,
> >
> > Chris
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>
>
>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message