• 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: Chuck Hill <email@hidden>
  • Date: Wed, 5 Jan 2005 20:02:04 -0800

Hi Nathan,

On Jan 5, 2005, at 7:39 PM, Nathan Hampton wrote:
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.


I think that inheritance is the best way to handle this. The parent entity would be Item and it would have RentalItem and PurchaseItem as the sub-classes.


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.

It is.  :-)  Well, at least more than the alternative below.


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.),
Yes. Probably more like:
http://xyz/WebObjects/Walla-Walla.woa
http://xyz/WebObjects/Spokane.woa

You're in Washington?

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.)?

You could probably make that work with some rewrite rules, but I would make different applications. There will be less to go wrong and it will be easier to add more instances if needed.

Chuck


--
Practical WebObjects - a book for intermediate WebObjects developers who want to increase their overall knowledge of WebObjects, or those who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects




_______________________________________________
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


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

  • Prev by Date: Re: Not Using Correct Session Sub Class?
  • Next by Date: RE: Null Pointer Exception in EOEditingContext._setRecordIsInitialized
  • Previous by thread: Re: Doubling Up
  • Next by thread: Using J2ME to invoke WO web services?
  • Index(es):
    • Date
    • Thread