struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <larry.mead...@gmail.com>
Subject Re: WAY OT Database Crossroads
Date Tue, 01 Feb 2005 17:23:02 GMT
I think I'd use a strategy pattern for this. Basically, one interface
with several implementations; the implementation is dynamically
selected at runtime, based on the tranaction type.

Larry

On Tue, 01 Feb 2005 12:19:03 -0500, Brandon Mercer <brandon@eutonian.com> wrote:
> Ok, I've officially NOT followed some standard somewhere.  :-(  Shame on
> me!  Can somebody help me with the following predicament?  I've got a
> table of transactions that need to be processed.  In that table I have a
> column for that persons account number... which gets assigned in a
> different table which is keyed on account number and transaction number
> :-(.  So I can't very well insert.... (break in thought) so I guess I
> don't NEED to key it on transaction because that particular table of
> information will only have ONE entry with one account number.  This
> brings me to my next crossroad.
> 
> Lets say that I have a table that has a field that references another table
> +--------------+---------------------+
>  | transcode |  typeoftrans      |
> +--------------+---------------------+
>  |00000002  | payment            |
> +--------------+---------------------+
>  |00000003  | transfer             |
> +--------------+---------------------+
> 
> and the value of transtype determines the next table that I have to
> insert information into.  How do I handle the insert of information in
> that scenario?  I've got as far as INSERTing it into the first table,
> recalling the transcode (which auto_inc), and I know the type of
> transaction before I do the insert.  Is it best to just have some logic
> in my data class that says if (typeoftrans.equals("somevalue")) {
> perform this insert
>     }
> I think I may have just answered my own questions... but I'm curious to
> see how the savvy struts pros would do it :-).  Thanks!
> Brandon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>

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


Mime
View raw message