RE: SQL STatements in a Properties file.
I must agree. 2 years ago I designed a small web application where my SQL
statements resided in a properties file and I cached them and retrieved them
at run time from the cache. Although some SQL statements could be tweaked
and cache updated without touching any code, some modified SQL statements
required code updates. The properties file was rather messy because some
statements were rather large. It also made it somewhat difficult navigating
between DAO and SQL properties file when I was debugging or reviewing the
code.
I have since changed my approach and included my SQL as static final data
members to my DAOs and have organized my DAOs from a business perspective
where they usually reside in the same package as my other business
components that support the appropriate business rules. I must say, this has
been much easier to maintain although a change in the SQL requires code
recompilation.
There may be a better approach, but this one has worked for me so far.
robert
> -Original Message-
> From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 8:43 AM
> To: Struts Users Mailing List
> Subject: RE: SQL STatements in a Properties file.
>
>
> If you have to do research for DAO's then it means that your
> documentation is poor. The person doing maintenance should have
> access to the DAO's and the documentation (SQL/JavaDoc). I find
> that putting all SQL's in one place gets ugly. After all, think
> of big systems where the queries are not only complex, but are
> miles long. Rather, with proper documentation, I can let people
> be pointed in the right direction and take appropriate decisions.
> This is one level of abstraction that I think is totally unnecessary.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 5:29 PM
> To: Struts Users Mailing List
> Subject: RE: SQL STatements in a Properties file.
>
>
> The reason for putting your SQL in a properties files is so that you or
> whomever is doing research or maintenance on the code can find all of the
> SQL in one place, instead of having to search all over for DAO's ( which
> can get pretty ugly). Abstraction is usually good, obfuscation is not
> good.
>
> Jim Berg
> Sr. Software Specialist
> PSCI
> 610-270-4158
> [EMAIL PROTECTED]
>
>
>
>
> "Vikram Goyal01"
>
>
> s.com>
>
> To: "Struts
> Users Mailing List", Struts-Atlanta
>
>
> 07-Jun-2002 00:55cc:
>
> Please respond toSubject: RE:
> SQL STatements in a Properties file.
> "Struts Users Mailing
>
> List"
>
> <[EMAIL PROTECTED]
>
> pache.org>
>
>
>
>
>
>
>
>
> I am not quite sure that putting your SQL in a properties file is such a
> good idea. Whats the advantage?
> If the advantage is that you dont have to change the source code
> because of
> query changes, then I think that it is misleading. If the query changes,
> there must have been a business requriement for it -- > you have to change
> functionality somewhere --> Means you have to change your source code to
> take advantage of this new query somewhere down the line (EJB, Action, JSP
> ) --> So you end up touching your source code. The whole idea of DAO's is
> to abstract your queries and data access. Having another level of
> abstraction is IMHO pointless.
>
> Rgs
> Vikram
>
> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 4:44 AM
> To: Struts Users Mailing List
> Subject: RE: SQL STatements in a Properties file.
>
>
> The framework knows nothing of sql.
>
> However, I have also pondered the using the message resources for
> something
> like this.
> I guess if your data layer had access to the message
> resourcesyou could
> do something like this.
>
> sql.customers.get=Select * from customers
> sql.customer.get=Select * from customers where id = {0}
> sql.customer.update=update customers set name={0}, address={1} where id =
> {3}
> sql.customer.delete=detete from customers where id = {0}
>
> Although, this can get pretty messy quickly.
> Have you considered using an OR tool???
>
>
> James Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://struts-atlanta.open-tools.org
> ICQ: 27651409
> AOLIM: jmitchtx (and NO I don't use AOL;)
>
>
> >
RE: SQL STatements in a Properties file.
If you have to do research for DAO's then it means that your documentation is poor.
The person doing maintenance should have access to the DAO's and the documentation
(SQL/JavaDoc). I find that putting all SQL's in one place gets ugly. After all, think
of big systems where the queries are not only complex, but are miles long. Rather,
with proper documentation, I can let people be pointed in the right direction and take
appropriate decisions. This is one level of abstraction that I think is totally
unnecessary.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 5:29 PM
To: Struts Users Mailing List
Subject: RE: SQL STatements in a Properties file.
The reason for putting your SQL in a properties files is so that you or
whomever is doing research or maintenance on the code can find all of the
SQL in one place, instead of having to search all over for DAO's ( which
can get pretty ugly). Abstraction is usually good, obfuscation is not
good.
Jim Berg
Sr. Software Specialist
PSCI
610-270-4158
[EMAIL PROTECTED]
"Vikram Goyal01"
To: "Struts Users Mailing List",
Struts-Atlanta
07-Jun-2002 00:55cc:
Please respond to Subject: RE: SQL STatements in a
Properties file.
"Struts Users Mailing
List"
<[EMAIL PROTECTED]
pache.org>
I am not quite sure that putting your SQL in a properties file is such a
good idea. Whats the advantage?
If the advantage is that you dont have to change the source code because of
query changes, then I think that it is misleading. If the query changes,
there must have been a business requriement for it -- > you have to change
functionality somewhere --> Means you have to change your source code to
take advantage of this new query somewhere down the line (EJB, Action, JSP
) --> So you end up touching your source code. The whole idea of DAO's is
to abstract your queries and data access. Having another level of
abstraction is IMHO pointless.
Rgs
Vikram
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 4:44 AM
To: Struts Users Mailing List
Subject: RE: SQL STatements in a Properties file.
The framework knows nothing of sql.
However, I have also pondered the using the message resources for something
like this.
I guess if your data layer had access to the message resourcesyou could
do something like this.
sql.customers.get=Select * from customers
sql.customer.get=Select * from customers where id = {0}
sql.customer.update=update customers set name={0}, address={1} where id =
{3}
sql.customer.delete=detete from customers where id = {0}
Although, this can get pretty messy quickly.
Have you considered using an OR tool???
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://struts-atlanta.open-tools.org
ICQ: 27651409
AOLIM: jmitchtx (and NO I don't use AOL;)
> -Original Message-
> From: Olikkadavath, Bobby [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 1:57 PM
> To: [EMAIL PROTECTED]
> Subject: SQL STatements in a Properties file.
>
>
> Hi,
> A newbie question...
> I want to dynamically pickup SQL queries from a Properties file
> (Similar to
> how we use the bean : Message and the ApplicationResourceProperties FIle
> for Static content in a JSP).
> Does the framework have an implementation exclusively for this or should
I
> create something on my own.
>
> Thanks
> Bobby
>
--
RE: SQL STatements in a Properties file.
The reason for putting your SQL in a properties files is so that you or
whomever is doing research or maintenance on the code can find all of the
SQL in one place, instead of having to search all over for DAO's ( which
can get pretty ugly). Abstraction is usually good, obfuscation is not
good.
Jim Berg
Sr. Software Specialist
PSCI
610-270-4158
[EMAIL PROTECTED]
"Vikram Goyal01"
To: "Struts Users Mailing List",
Struts-Atlanta
07-Jun-2002 00:55cc:
Please respond to Subject: RE: SQL STatements in a
Properties file.
"Struts Users Mailing
List"
<[EMAIL PROTECTED]
pache.org>
I am not quite sure that putting your SQL in a properties file is such a
good idea. Whats the advantage?
If the advantage is that you dont have to change the source code because of
query changes, then I think that it is misleading. If the query changes,
there must have been a business requriement for it -- > you have to change
functionality somewhere --> Means you have to change your source code to
take advantage of this new query somewhere down the line (EJB, Action, JSP
) --> So you end up touching your source code. The whole idea of DAO's is
to abstract your queries and data access. Having another level of
abstraction is IMHO pointless.
Rgs
Vikram
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 4:44 AM
To: Struts Users Mailing List
Subject: RE: SQL STatements in a Properties file.
The framework knows nothing of sql.
However, I have also pondered the using the message resources for something
like this.
I guess if your data layer had access to the message resourcesyou could
do something like this.
sql.customers.get=Select * from customers
sql.customer.get=Select * from customers where id = {0}
sql.customer.update=update customers set name={0}, address={1} where id =
{3}
sql.customer.delete=detete from customers where id = {0}
Although, this can get pretty messy quickly.
Have you considered using an OR tool???
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://struts-atlanta.open-tools.org
ICQ: 27651409
AOLIM: jmitchtx (and NO I don't use AOL;)
> -Original Message-
> From: Olikkadavath, Bobby [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 1:57 PM
> To: [EMAIL PROTECTED]
> Subject: SQL STatements in a Properties file.
>
>
> Hi,
> A newbie question...
> I want to dynamically pickup SQL queries from a Properties file
> (Similar to
> how we use the bean : Message and the ApplicationResourceProperties FIle
> for Static content in a JSP).
> Does the framework have an implementation exclusively for this or should
I
> create something on my own.
>
> Thanks
> Bobby
>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: SQL STatements in a Properties file.
- Original Message -
From: "James Mitchell" <[EMAIL PROTECTED]>
> The framework knows nothing of sql.
>
> However, I have also pondered the using the message resources for
something
> like this.
> I guess if your data layer had access to the message resourcesyou
could
> do something like this.
>
> sql.customers.get=Select * from customers
> sql.customer.get=Select * from customers where id = {0}
> sql.customer.update=update customers set name={0}, address={1} where id =
> {3}
> sql.customer.delete=detete from customers where id = {0}
>
> Although, this can get pretty messy quickly.
> Have you considered using an OR tool???
>
>
> > -Original Message-
> > From: Olikkadavath, Bobby [mailto:[EMAIL PROTECTED]]
> >
> > Hi,
> > A newbie question...
> > I want to dynamically pickup SQL queries from a Properties file
> > (Similar to
> > how we use the bean : Message and the ApplicationResourceProperties
FIle
> > for Static content in a JSP).
> > Does the framework have an implementation exclusively for this or should
I
> > create something on my own.
> >
> >
I'm doing something VERY similar to this on a current project. The problem
that I was addressing is that I am working at home using MySQL as my dev db,
but then deploying at the client site to Oracle. In certain cases the syntax
of the queries is different (different outer join syntax, and Oracle uses
substr() where MySQL uses substring()). It was a pain commenting out SQL
statements and remembering to recompile with the correct statements each
time.
I moved only those statements that varied into a properties file that is
specific to my data layer. I agree tht if all statements were retrieved from
the properties file, or if they were stored in the application properties
file, it could get rather ugly. But I don't think that they belong in the
application properties file anyway. These statements are specific to the
data access layer, and it makes sense to me to place them in a properties
file specific to that module. This has been working very well for me.
Dave D
--
To unsubscribe, e-mail:
For additional commands, e-mail:
RE: SQL STatements in a Properties file.
I am not quite sure that putting your SQL in a properties file is such a good idea.
Whats the advantage?
If the advantage is that you dont have to change the source code because of query
changes, then I think that it is misleading. If the query changes, there must have
been a business requriement for it -- > you have to change functionality somewhere -->
Means you have to change your source code to take advantage of this new query
somewhere down the line (EJB, Action, JSP ) --> So you end up touching your source
code. The whole idea of DAO's is to abstract your queries and data access. Having
another level of abstraction is IMHO pointless.
Rgs
Vikram
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 4:44 AM
To: Struts Users Mailing List
Subject: RE: SQL STatements in a Properties file.
The framework knows nothing of sql.
However, I have also pondered the using the message resources for something
like this.
I guess if your data layer had access to the message resourcesyou could
do something like this.
sql.customers.get=Select * from customers
sql.customer.get=Select * from customers where id = {0}
sql.customer.update=update customers set name={0}, address={1} where id =
{3}
sql.customer.delete=detete from customers where id = {0}
Although, this can get pretty messy quickly.
Have you considered using an OR tool???
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://struts-atlanta.open-tools.org
ICQ: 27651409
AOLIM: jmitchtx (and NO I don't use AOL;)
> -Original Message-
> From: Olikkadavath, Bobby [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 1:57 PM
> To: [EMAIL PROTECTED]
> Subject: SQL STatements in a Properties file.
>
>
> Hi,
> A newbie question...
> I want to dynamically pickup SQL queries from a Properties file
> (Similar to
> how we use the bean : Message and the ApplicationResourceProperties FIle
> for Static content in a JSP).
> Does the framework have an implementation exclusively for this or should I
> create something on my own.
>
> Thanks
> Bobby
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: SQL STatements in a Properties file.
The framework knows nothing of sql.
However, I have also pondered the using the message resources for something
like this.
I guess if your data layer had access to the message resourcesyou could
do something like this.
sql.customers.get=Select * from customers
sql.customer.get=Select * from customers where id = {0}
sql.customer.update=update customers set name={0}, address={1} where id =
{3}
sql.customer.delete=detete from customers where id = {0}
Although, this can get pretty messy quickly.
Have you considered using an OR tool???
James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://struts-atlanta.open-tools.org
ICQ: 27651409
AOLIM: jmitchtx (and NO I dont use AOL;)
> -Original Message-
> From: Olikkadavath, Bobby [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 1:57 PM
> To: [EMAIL PROTECTED]
> Subject: SQL STatements in a Properties file.
>
>
> Hi,
> A newbie question...
> I want to dynamically pickup SQL queries from a Properties file
> (Similar to
> how we use the bean : Message and the ApplicationResourceProperties FIle
> for Static content in a JSP).
> Does the framework have an implementation exclusively for this or should I
> create something on my own.
>
> Thanks
> Bobby
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
SQL STatements in a Properties file.
Hi, A newbie question... I want to dynamically pickup SQL queries from a Properties file (Similar to how we use the bean : Message and the ApplicationResourceProperties FIle for Static content in a JSP). Does the framework have an implementation exclusively for this or should I create something on my own. Thanks Bobby
