I intend to have multiple Rails apps each for site.com, api.site.com, admin.site.com. All apps will access the same tables from one single MySQL database. Apps and database runs in the same server.
Is there any settings in Rails, ActiveRecord or MySQL that I need to be concerned about for above access scenerio? Thanks
Running: Rails 2.3.5, MySQL 5.0, Nginx, Passenger, RubyEE
This configuration tends to be quite difficult to maintain.
In every app, you would need to keep schema.rb and models in sync in order to use the same database. It means lot of duplication.
This isn't probably a good idea. Instead, you might want to design the application to meet one of the following scenario:
one Rails application which handles site.com, api.site.com and admin.site.com (why do you need separate app?)
multiple Rails applications, but just one interact with the db. The others uses the main application API (quite complex)
different apps with different purposes (for instance, you might want to use Sinatra + Datamapper for api.site.com)
The first option is probably the best one in most cases.
I answered similar question here. You can do it and sometimes it is reasonable.
Related
I'm creating a mobile app for an existing website and trying to connect to a local instance I have running on a MySQL workbench. I've seen others recommend against the use of MySQL but I'm stuck with it, since that's the current database. I'm using expo to run my React Native code. Do I need to use a server, like "MAMP?"
Let me know if there is any more info that is needed.
You cannot connect your app directly to your database.
You will need a server/API that acts as an intermediate between the app and the DB. You can code it in most programming languages and if you know PHP, having MAMP on your system will allow you to build your API with PHP.
I've seen others recommend against the use of mySQL
You should definitely question their reasoning. I've been using MySQL for many years now in small and big projects and it has never been an issue. If they're comparing it to non-relational DBs like Mongo, I can understand, it's easier to setup and maintain a NoSQL database than a relational one.
I assume you're not that experienced but I still purposefully used some terms that may be new to a beginner. Since I don't know your skills, I will refrain from pointing you to specific tutorials/articles.
I recommend you to Google anything you don't understand from this answer.
There are similar posts like this on the internet, but they seem to be targeted towards lower level languages like Java. NetBeans for example seems to have this kind of functionality.
Here is what I want to do:
I have a large dataset of items. I want to create a RESTful API that would enable my users to perform complex queries to retrieve data from the MySQL database on my backend.
The API needs to be able to:
SELECT a table to retrieve values from
Be able to use common MySQL aggregate functions such as COUNT, SUM,
and AVG on the results
Create WHERE conditions
Security is not an issue as this my simply an MVP for now. On a future iteration I will take security into consideration. Are there any Ruby gems which provide a framework for constructing this kind of system?
I am open to using either Sinatra or Rails for this system.
Maybe this can help you:rails-api
Rails::API is a subset of a normal Rails application, created for
applications that don't require all functionality that a complete
Rails application provides. It is a bit more lightweight, and
consequently a bit faster than a normal Rails application. The main
example for its usage is in API applications only, where you usually
don't need the entire Rails middleware stack nor template generation.
or you can use grape gem.
I'm working on a bunch of cakephp apps that are all services that you have access to when you login to the main website. Each app will be hosted on a separate server, and there will be a separate login server as well.
Doing the research, I found Cakephp supports writing sessions to a database, http://blog.jambura.com/2011/08/24/should-i-use-database-for-storing-sessions-in-cakephp/
And also it supports having multiple database connections,
http://bakery.cakephp.org/articles/mithesh/2008/09/02/talking-to-multiple-databases-from-single-cakephp-application
So I was considering the possibility of storing the sessions on the login server, which the other websites all access, and then they all use their own databases for the rest of their data. It seems like it would be simple to implement, but I have concern that there would be too much reading and writing on the login server's database. Is there a way to optimize for this? Or should I do another approach entirely?
Try check useDbConfig property of model. Think, that it will be simpler if your sessions and users tables will be on the same database, then you will common user database and sessions. So, you will not require to implement SSO.
In our rails app we sometimes have db entries created by users that we'd like to make part of our dev environment, without exporting the whole table. So, we'd like to be able to have a special 'dev and testing' dump.
Any recommended best practices? mysqldump seems pretty cumbersome, and we'd like to pull in rails associations as well, so maybe a rake task would make more sense.
Ideas?
You could use an ETL tool like Pentaho Kettle. Once you have initial transformation setup that you want you could easily run it with different parameters in the future. This way you could also keep all your associations. I wrote a little blurb about Pentaho for another question here.
If you provide a rough schema I could probably help you get started on what your transformation would look like.
I had a similar need and I ended up creating a plugin for that. It was developed for Rails 2.x and worked fine for me, but I didn't have much use for it lately.
The documentation is lacking, but it's pretty simple. You basically install the plugin and then have a method to_sql available on all your models. Options are explained in README.
You can try it out and let me know if you have any issues, I'll try to help.
I'd go after it using a Rails runner script. That will allow your code to access the same things your Rails app would, including the database initializations. ActiveRecord will be able to take advantage of the model relationships you've defined.
Create some "transfer" tables in your production database and copy the desired data into those using the "runner" script. From there you could serialize the data, or use a dump tool, since you'll be dealing with a reduced amount of records. Reverse the process in the development environment to move the data into the database.
I had a need to populate the database in one of my apps from remote web logs and wrote a runner script that fired off periodically via cron, ftps the data from my site and inserts the data.
I'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.