• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Doubling Up
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Doubling Up


  • Subject: Re: Doubling Up
  • From: Nathan Hampton <email@hidden>
  • Date: Wed, 5 Jan 2005 19:39:21 -0800

Hi Chuck,

On 05 Jan 2005, at 1:08 PM, Chuck Hill wrote:

Hi Nathan,


On Jan 4, 2005, at 9:40 PM, Nathan Hampton wrote:

I'm grafting a web ordering interface onto a legacy system that uses a SQL Server database on the back end. The way the project is working out, I only have to interface with the database, which is making my life a whole lot easier. Unfortunately, "easier" is a relative term, so I'd love some input on how to handle these.......

1) Right up front, let me tell you that the existing database is a bit bizarre. I didn't design it; I just have to work with it. In this database are two tables containing item information. Both have exactly the same attributes, and are referenced interchangeably from other tables. (Did I mention that there are no foreign key constraints to manage the relationships? Grrrrrr....)

What is the difference between the two? Is the information duplicates, or just split into two tables for some other reason?

One table contains information on items for rent; the other, items for sale.


What I'm not sure of is how I should model these tables and their relationships. Is this a place to use inheritance? Horizontal inheritance seems to be closest to what I want, so would I create a superclass which has two subclasses with identical attributes? Alternatively, should I try to fool EOF into thinking that they're really one table by creating a view in the database that is a union of the two tables? If I follow this approach, how much of a load will I be adding to the database server?

Inheritance might be a solution, I'm still puzzling over the why. If we know that it may be easier to recommend a path.

I have absolutely no idea why it was set up this way. It's my understanding that the setup dates back to the original system, which was done in Fox Pro, and was later converted to the current system of MS SQL Server with a VB front end.


If it helps, I only have to read from these tables, not write to them. (I may also need to add duplicates of tables I have to write to, such as the InvoiceHeaderHistory table, which contains historical data from the InvoiceHeader table that I need to write to, but that would be later.)

There is a section in Practical WebObjects on copying EOs. You can probably modify that to create this history.

Thanks. I haven't made it all the way through yet, but I like what I've seen so far.


2) This project will work with four identical databases, each representing one of the company's four locations. I'd like to use the same EOModel for all four, since they have the same structure, but I need to figure out how to connect to the appropriate database on a per-session basis. I think I can get away with making the user specify which of the four locations they use (they're in four different major metropolitan areas, so users are unlikely to get confused about which one to select), but how would I use that information to tell the application which database to use? Or do I need to have four (identical) EOModels, and have the user input select the appropriate model, and, therefore, the relevant database? Or is there another way I haven't thought of?
If you do this all in one app, then you will need to manage a pool of four EOF stacks. You will need to manually create each EC using new EOEditingContext(EOObjectStoreCoordinator). You will need to set these stacks up manually, set the connection dictionary when each is created, and manage using the right one for a particular session.
This sounds complicated.

An alternative worth considering is to run an instance of your app for each city, rather than having one instance handle all of them. That would be a lot easier to setup. You would just create new applications in JavaMonitor (same .woa but a different app name in JM) and pass in the JDBC URL as a launch arg.
I think I'll try it this way, and not even use WO until they choose which location to order from. Would I need to have multiple applications using the same .woa (http://xyz/WebObjects/Spokane/, http://xyz/WebObjects/Walla-Walla/, etc.), or could I pass the JDBC URL to four instances of the same application (instance 1 of http://xyz/WebObjects/OrderOnline/ is Spokane, instance 2 is Walla-Walla, etc.)?

--NCH

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Doubling Up
      • From: Chuck Hill <email@hidden>
References: 
 >Doubling Up (From: Nathan Hampton <email@hidden>)
 >Re: Doubling Up (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Not Using Correct Session Sub Class?
  • Next by Date: Re: Not Using Correct Session Sub Class?
  • Previous by thread: Re: Doubling Up
  • Next by thread: Re: Doubling Up
  • Index(es):
    • Date
    • Thread