• 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: Multiple Databases
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple Databases


  • Subject: Re: Multiple Databases
  • From: Colin Clark <email@hidden>
  • Date: Sun, 7 Mar 2004 20:00:30 -0500

Hi Brin,

Multiple data sources are simple to work with in EOF. I think you'll find the Enterprise Objects book will answer most of your questions, particularly the "Connecting to a Database" section, which includes information on multiple data sources.

http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/ index.html

Basically, you'll just need to create another EOModel for your authentication database and include it in the application. EOF will do the work of deciding which data source can satisfy a particular fetch specification, so in a basic scenario your application doesn't even need to know that users are stored in a different database from the rest of your data.

I'm guessing from your description that the other databases (the ones that don't store user information) probably have the same schema but different data. In that case, all you need to do is write some simple code to create a new EOF stack, change the connection dictionary and dynamically reconnect to the correct database. This will likely be done on a per-session basis for your needs.

I'm not sure what you mean when you mention assigning "EOModels to sessions." I can understand having different database connections for different sessions, but completely different EOModels for each session?

Colin

On Sunday, March 7, 2004, at 10:24 AM, Support wrote:

We are just starting down the road of WO development. I am sure this has been asked before, but after looking through a variety of sources we are still at a loss.

We will be maintaining our list of users in one database for single sign-on capability. Then each user when they login will access information from their database. So that we have one login database and multiple databases. We have to maintain different databases for each group of users for security reasons.

So far from reading, the secret seems to be in the connection dictionaries?

When a user logs in ideally we want this to happen:

1. Authenticate against the user db. In other places in the application this authentication is required again. So the connection should either be active OR easy to call at any time.

2. The authentication returns the name of the database assigned to that user, and stores it as a session variable so that it is passed from page to page until the session has expired or the user logs out.

3. The connection is made to the users database.

Everywhere we look it seems that it is One EO model to one instance of WO.

We don't want to create multiple instances of the application since most session are left to expire and this will be a memory hog? But this has to be easy to do in WO, since it seems to be for other tools, right?

So we need to assign EO Models to sessions, at least that is how we do it now and it works great.

Thanks for help in advance,

Brin
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >Multiple Databases (From: Support <email@hidden>)

  • Prev by Date: Re: One App, db connection onload, depending on WebAdress
  • Next by Date: Can't insert a second record?!
  • Previous by thread: Multiple Databases
  • Next by thread: Relationships, database, refresh, etc...
  • Index(es):
    • Date
    • Thread