You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 22, 2022. It is now read-only.
Is your feature request related to a problem? Please describe.
The Library Location, Item Types, Circulation Rules and Statuses are all information coming from Symphony WebServices. It comes to the application in the form of a short code 'UAINTERNET' or '1WK-25-2R' but we want to display 'University of Alberta Internet' or '1 week loan/.25 fine/2 renewals'.
Describe the solution you'd like ualbertalib/discovery#1843 Set up data synchronization between Symphony and Discovery DB. We'd like to leverage this to populate the NEOSDiscovery tables.
You can have some models in one database (the ones that you want to share), and others in the new app's own database (so they don't collide with the existing app).
To specify a different database for a particular model, try something like this:
SharedModelBase < ActiveRecord::Base
self.abstract_class = true
establish_connection(ActiveRecord::Base.configurations["shared_db_connection_#{RAILS_ENV}"])
end
Now, use this as a base class for your shared models, and you should be good to go.
One option is to not even try to access to the db directly, but instead build an integration between the apps using ActiveResource. Have the original app provide a RESTful interface to these tables, and consume it in the new app, and don't share the db at all.
Another option is to refactor these shared tables into their own database, and have both the rails apps access that db. You could even end up writing services (e.g. restful interface) to this shared data to be used by both apps, and then you are nicely decoupled.
Another option is to keep two databases in the two applications but let the automation scripts update both applications independently from the same data.
The trouble with sharing this is that the Discovery and NEOSDiscovery applications will have to change in lock-step (any migrations requiring changes to code need to happen at the same time in both applications).
There are modifications needed to both the applications laid out in the above pull requests. Neil would need to copy the migrations to the NEOSDiscovery application db/migrate directory and run rake db:migrate there as well.
Still feel like this would be the easiest thing to do and confirmed that it will work. Dump just the tables of interest from Discovery and import them to the NEOSDiscovery database.
Seems like it would work the best in practice because it avoids the need to copy and load data. However, I wasn't able to prove the viability of this idea within the duration of the spike. Was not able to solve the issue of
ActiveRecord::ConnectionTimeoutError at /
could not obtain a connection from the pool within 5.000 seconds (waited 5.000 seconds); all pooled connections were in use
Is your feature request related to a problem? Please describe.
The Library Location, Item Types, Circulation Rules and Statuses are all information coming from Symphony WebServices. It comes to the application in the form of a short code 'UAINTERNET' or '1WK-25-2R' but we want to display 'University of Alberta Internet' or '1 week loan/.25 fine/2 renewals'.
Describe the solution you'd like
ualbertalib/discovery#1843 Set up data synchronization between Symphony and Discovery DB. We'd like to leverage this to populate the NEOSDiscovery tables.
Describe alternatives you've considered
From here
To specify a different database for a particular model, try something like this:
Now, use this as a base class for your shared models, and you should be good to go.
One option is to not even try to access to the db directly, but instead build an integration between the apps using ActiveResource. Have the original app provide a RESTful interface to these tables, and consume it in the new app, and don't share the db at all.
Another option is to refactor these shared tables into their own database, and have both the rails apps access that db. You could even end up writing services (e.g. restful interface) to this shared data to be used by both apps, and then you are nicely decoupled.
Another option is to keep two databases in the two applications but let the automation scripts update both applications independently from the same data.
The trouble with sharing this is that the Discovery and NEOSDiscovery applications will have to change in lock-step (any migrations requiring changes to code need to happen at the same time in both applications).
#320
The text was updated successfully, but these errors were encountered: