Initially I built a forum on rails with the user and the post model but now I am planning to pivot to something else and I don't need the posts functionality anymore.
My question is how do I completely delete it and what would be correct order if I have to just delete the files generated.
By deleting I mean everything like that feature never existed in the app, no database connections and no properties remaining on the other user model.
I am not sure how I do I proceed, there are many ways to do it, by running commands or by just deleting the generated files but I want to know the correct way because I don't want to run into trouble if something goes wrong.
There is no "correct" way, just delete the files, create a migration removing the tables and then audit your remaining files for methods that are no longer used.
In simple cases, you can use the generators that generated your code to also remove that code. If you used rails generate model MyModel to produce your model and migration, you can use rails destroy model MyModel.
Related
Sorry that this question is not a proper one on this site, but I really thought that I needed to know how to do that, because in production environment, if I delete all data all the time when I delete a model, this should be a serious problem.
In detail
In case re-making the same named model,I mean after delete a model, then make the same named model.
It should be like
rails destroy model Name
and after that
rails g model Name
And usually errors occur in this case, we can basically fix the errors by using the command rails db:schema:load, but this command destroys whole data of an existing database, but I don't want to lose the data so I wonder if there are any other good ways for this.
Thanks
Normally, this should not affect your production database, since Ruby on Rails knows what migrations have run already and that's why you should use rails db:migrate to update your database.
If your production database has old entries that you want to reuse, you can also change the Active Record Migrations so that the affected table does not get dropped and recreated but altered instead.
I'm facing a complex problem which i haven't been able to resolve yet.
I'm using Rails 4(edge) with postgresql 9, ElasticSearch 0.20.6 and the gem Tire (0.5.7).
I have multiple table that are linked together. for instance:
Agency has many Clients
Clients has many Projects
Projects has many Files
My goal here is to be able to index Files in two ways:
First have an index that just allows easy and rapid search among all files. That i have succeeded into doing just by using tire. My index has a type "file" and it works like a charm.
The other index I would like to create would have some of the files information but also some of the clients and the agencie's properties. This is for an external tool that would be able to fetch the best files according to criteria like the project's category or the client's location...
As i'm using postgresql, i was thinking i could do a database view and index data from there. I'm not sure it's good to do it like that though cause the view would be pretty complex with multiple joins. Plus i'm afraid that any update would trigger a full-database re-indexing.
I was wondering if there was a way to do a pure-tire model and easily trigger the index update on any of it's linked tables.
For instance, i'll have indexed the data in a type named files_front. I would have a model FilesFront which has_one :file and each time i update a file or any parent, all the impacted files would see their values updated in ES.
I'm really not sure on how to do this, so any advice is welcome.
Having a separate, table-less or standalone model is a good solution. The problem here, I assume, is connecting the FileFront class to the rest of the system. Effectively, whenever you update the File or any associated Client etc. object, you need to update the FileFront object.
You could actually use the Model::Persistence to that. So for each File you'd have an associated FrontFile, which you would assemble as JSON in File and create/update in an after_save callback. The tricky part is ensuring changes to the parent objects are propagated to file, and vice-versa.
I have an existing database in which I am converting a formerly 'NULL' column to one that has a default value (and populating that with said default value). However, that value is an ID of a record I need to create. If I put this record in db/seeds.rb, it won't run because db/seeds.rb runs after migrations -- but the migration needs seed data. If I leave the record creation in the migration, then I don't get the record if I make a fresh database with db:load. Is there a better way other than duplicating this in both db/seeds.rb and the migration?
Thanks!
While I can understand your desire to stay DRY and not have to write this in both the migration and seeds.rb, I think you should write it in both places. Not just to make it work, but to accomplish different requirements related to your problem.
You need to ensure that your migration can execute properly regardless of external processes. That means you should put any code required within that specific migration. This isn't to accomplish anything besides making sure your migration executes properly. Suppose someone else tries to migrate without knowing you put part of the code in seeds.rb, it would be very difficult for them to figure out what's going on.
You can make db:load work properly by including similar code in seeds.rb. However, you should be evaluating the current state of your database in seeds.rb due to the fact that it runs after the migrations. So you can check to see if the column exists, and what the default value is etc. This means that if the migration ran and took care of everything, seeds.rb doesn't repeat work or modify values inappropriately. However, if the migration did not set these variables as expected, it is able to set the values.
I'd recommend looking at it as two separate issues so you can be more confident of each one executing successfully independent of one another. It also creates better maintainability for understanding by yourself or others of what's happening in the future.
In my opinion you should treat this in both db/seeds.rb and the migration.
The migration is used to get an existing database from an older version to another version while seeds.rb and schema.rb are used for a fresh database with the latest version.
I'm trying to modify an existing Ruby on Rails project. I understand that forms and models are closely related. I'm trying to understand how to modify a form so that instead of accepting an upload, it stores a timestamp instead. So, my understanding is that I need to modify the view and the model. Is there anything else I need to modify? What happens to existing data that I have stored in ActiveRecord?
Unless you remove columns from the table with a new migration - data will be safe. It's a good practice to write tests, so when such situations occur that you need to modify something - you can test that everything still works.
Btw, I don't understand the logic that you are trying to implement. The form was uploading some file before, and you need to change that and remove the file upload and modify some timestamp in the record?
Your existing data is supposed to be fixed up with a migration, which you will need to write.
I have been tasked with developing a new retail e-commerce storefront for my current job, and I am considering tackling it with RoR to A) Build a "real" project with my limited Rails knowledge, and B) Give management quick turnaround and feedback (they are wanting to get this done ASAP and their deadlines are rather unrealistic - I'm talking a couple of weeks to go from nothing to working model so they can start to market it with SEO/SEM and, I kid you not, "video blogging" because my boss heard that's the future).
We do have a database structure in place but it's absolutely terrible and was thrown together without rhyme nor reason, so I'm going to largely ignore it and create a new database from scratch; however, I have existing data that I need to load into the application (like I said, it's an e-commerce app and we have the product data). I need to massage this data into a usable format because our supplier provides it to us with cryptic, abbreviated column names and it's highly denormalized, especially in the categories (I've posted a question regarding it before - basically the categories table has six fields, one for each category/subcategory, with some of them being blank if that category doesn't apply).
There are two main issues that are giving me second thoughts:
As I said the data needs to be put into a "proper" database schema; I can't just load it as-is. I have some thoughts as to a good data model for it, but my analysis is not completed yet. There would end up being a large amount of joins tables to link various things together (e.g. products_categories, products_attributes, products_prices) etc and these tables would link products not via an ID but by their SKU (see below).
Everything already has an ID that's generated for it, but anything new I add needs to have one autogenerated; I doubt this will be a problem with any mature RDBMS, but I know Rails likes to generate IDs itself. Also, almost all of the product-related tables are linked by SKUs (and in the data provided by the supplier are actually a composite key consisting of the prefix and stock number, which combined make up the full SKU), not by IDs and I'm not sure if this will be a performance issue (of course, I could always manually create indexes on these columns to speed it up). It does mean that I'll need to break away from the Rails conventions, however.
In short, I think that Rails might be a good choice as far as time-to-market and ease-of-development, but having to work with the existing data content might turn into a pain because the application will need to be developed around that, instead of the "traditional" Rails app, and that factor is giving me major doubts about using Rails. There are also some other issues (having to set up a Linux server, and the fact that the area I live in has very few Rails developers so if I left the company I'd basically be holding them hostage as far as updates/modifications). I'm really unsure as to the best path to proceed.
I would develop the app as if you didn't have the data. Use the ORM and make your database the best it can be, but of course keep in mind what data you have to populate it with (eg: don't make crazy new constraints for things that will leave you going through old data record by record).
When you're done and tested, write an import script that pulls your real data onto your new database.
It's not that different from the conventional design/development model... Apart from you can do your data-input in a semi-automated fashion.
I was in the same situation not too long ago — a crappy PHP app that held ten years worth of all company data.
What I did was simply create a Migration model and added methods to import each resource.
class Migration
def migration_all
self.jobs
end
def self.jobs
...
end
end
The cool thing about this is that you can arrange which order resources are imported as one will likely reference another. I also added methods that directly modified the db schema. One nice trick if you have to keep an existing primary key is to create a field named 'legacy_id', copy over your existing primary key, and when you're done, simply remove the 'id' field, rename the 'legacy_id' field to 'id', then add the primary_key constraint on the new 'id' field.
Don't use the SKU as the unique key for each product - use the standard Rails incremented id.
SKU could change as it may be misentered, etc and that would make it a nightmare to change all of the references from other tables. Put your current id in a sku column, index it and update the references in your other tables to the Rails ids.
You'd be able to do Product.find_by_sku(params[:sku]) in your controllers, set up a /products/:sku route, etc. I don't see what you'd gain (other than a headache) by using your non generated ids as the database primary keys.
I'd also suggest running your old data through your app's validations to make sure you are not loading up a bunch of inconsistencies and erros. It will help your app run smoothly and highlight existing data errors at a point where you can fix them.
Don't assume the existing data is valid just because it is already there.