I would like to create a new app rails but being a beginner it's been several days that I try several possible ways without really finding the right one, I just managed to do something but I'm not sure that it's perfect in terms of relationships. the concept would be that people could either create or participate in meals. I would like the ingredients to be reusable, but their attributes such as the origin or cooking method can be modified in each case. do you think this style of rallying is fair?
or
The second option is a classic one. Stick to using many-to-many relation in that cases.
Though it is better to have one-to-many relation between specification and menu - like several specifications for each menu. And specification should also contain ingredient_id.
Related
Ive been working on an app for table-top RPG games that is meant to be universal for all games. Currently the way im doing this is with a combination of a specific tables for each game (with columns for each attribute) and also making universal tables for things like equipment, attacks, etc. This is working but the tables are getting a little complex and hard to handle with multiple nested relationships.
I stumbled upon rails ActiveRecord Store and think this is a better option as I could serialize the attributes into a single column and the views would handle saving and loading the right variables from the serialized column.
Im wondering if I am missing something or is this a valid option?
It sounds like a great option. Write lots of tests. Try it out.
There's nothing wrong with hundreds of tables. It can help in terms of organization to separate models into namespaces.
I have 3-4 different types of clients for a photo site. Musician, wedding, portrait, and general with the possibility of adding more types. The idea is each type will have a shared set of attributes such as name email etc. but each will have their own too.
Musicians will have band name, members, genre, while wedding will have venue, coordinator details and so on.
I think this is the right way to go about it, correct me if there's an easier way to track multiple shared and unique attributes.
I was reading up on single table inheritance and one place said to use it only if the models have the same attributes but different behavior. How can I structure my models to meet this? From a more generic OOP standpoint this makes a lot of sense to me, but I'm having doubt's from that clause of STI.
Your use case sounds like a good one for STI. The key thing is that the children share some attributes with their siblings, not all attributes. I found this overview helpful:
http://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-1/
I am looking for a way to add a lot of records at ones in ActiveAdmin. To be more specific, I have 2 models: Stores and Programs. Stores have many Programs.
I don't mind adding a Store using standard ActiveAdmin create view. But I would like a faster way to add programs in a spreadsheet-like way. I looked into best_in_place (https://github.com/bernat/best_in_place) but it doesn't do do adding records, just editing them.
Any suggestions? I would really appreciate it.
The short answer is Rails has nothing to help you do this. Rails has a defined convention for editing multiple objects if they belong to another object that can accept nested attributes for a few reasons, the most important of which is that there's a place to aggregate validation, as well as a standard way to differentiate each set of fields (the id). Neither of these are true during creation.
You can, however, manually work around this a couple of ways.
would be to simply write out the forms yourself, and put the logic to loop through them in your controller. This is going to be fragile, and you'll have issues getting validation to work properly, however.
would be to either create a new class that handles this single case, or try and adapt your existing Store class to handle nested attributes. There's a very solid explanation of how to do this here.
I'm new to rails, so be nice.
I'm building a "rolodex" type application, and this question is about the best way to handle creating an entity along with several relationship entities at the same time.
For (a contrived) example:
My application will have a Person model, which has_one Contact_Info model. On the create.html.erb page for Person it makes sense for the user of my appliction to create the person, and the contact_info at the same time.
It doesn't seem right to include details for creating a contact directly in the create view/controller for person. What's the rails way to handle this?
Using nested attributes is the most common way to do this.
The actual documentation is here.
You want to use "Nested Forms". There is a great example of them in this blog post.
I'm also noob, but I had a similar issue with an app. I was using a tutor at the time and he basically said it was a good example of rails being opinionated. It sounds like you want to take the create action for two different models at the same time, which may be possible but probably very hard. Id suggest considering whether your data model could be modified, or find a way to make an acceptable user flow while collecting the data in different forms.
Update: while writing this the technical answer came in. Keep in mind, its perfectly okay to take the easy route if doing so helps you get the app out the door, and especially while you're still new.
I've just been reading Chad Fowler's blog post about 20 Rails Development No-Nos. On Single Table Inheritance he comments:
The storage of a column called “type” which holds a class name is a pretty good indicator that something fishy is going on. It’s fishy but not always bad. I think, though, that any time you use it you should ask yourself more than once if it’s the right solution. Databases don’t do what they do best as well when you have lots of STI and polymorphic associations.
I'm writing a blog application and I'm considering using STI for the comments that can be made on a post and for the contact messages that visitors can post if they want to get in touch with me. My Message model will inherit from my Comment model. They both share common attributes, except that Message will have an extra subject field. Another commonality is that both will be submitted to Akismet for spam checking.
Rather than just ask myself more than once if it's the right solution as Chad suggests, I thought I'd get some opinions from the Stack Overflow experts as well! Does what I'm proposing sound like a good fit for STI?
I've used STI a number of times. Consider a CMS which might have Page, NewsItem, BlogItem etc.
They could each descend from a common class which in turn inherits from ActiveRecord. The table for each would be the same (title, body, tags, published_at) but each model might have different associations, or different statuses, or a different workflow so each has custom code in their own class. Yet they all share a common table and parent class. It also allow me to use the parent class to do a cross class search and have the resulting Array of records automatically type cast.
There are other ways to tackle this and maybe not the best example but there are certainly times when STI is handy for situations where object behavior may differ but persisted state is the same. Of course you have to be sure this is also true in the future.
In your case comments and contact messages are different. It sounds like there is there no benefit by having them in the same table. Maybe put shared code in a parent class or better still in a module in /lib.