Since you don't have control over the originating data-source...like i said Scenario 1 would work just fine.
On Tue, Oct 13, 2015 at 10:47 PM, David McDonald <daveo...@gmail.com> wrote: > I get my data from a database that I have access to that is updated at > different points during the day. As far as having a custom validation > method, I have that. Here's a, hopefully, more descriptive example of what > is going on. > > I have my Rails app, and I import records into that database on a daily > basis from a database I have no control over. During importing of those > records some pass my validations and some do not. I have some methods in > place that will attempt to correct the column's data that is failing my > validation, but sometimes they can't be corrected unless they have a user > manually look into it and correct that data. I'm attempting to come up > with a solution that allows me to get a list of those records that failed > validation to allow a user to use my app to change the problem information > and then attempt to save the record to the database. > > > On Tuesday, October 13, 2015 at 5:37:27 PM UTC-4, mode-x wrote: >> >> You don't need to create another table also. You just need a custom >> validation method that handles the checking of the imported data. And in a >> before_save this can be implemented. Also If there is an error send a >> notification to the owner of the record via email or when next the user >> tries to access the application redirect the user to make corrections >> before they proceed. *Scenario 1 *is seem good but don't play with >> invalid data in your database. >> >> On Tue, Oct 13, 2015 at 10:22 PM, Emmanuel Abia <abia...@gmail.com> >> wrote: >> >>> Avoid BY ALL MEANS any procedure that might complicate maintenance for >>> you both short term and long term. >>> I would advice you that you reconsider the approach. Rails has good >>> validation methods that will make your programming life sweet and fun. What >>> you are doing doesn't seem like fun to me. With Rails you can make tables >>> to validated each other also perform custom validations etc. However when >>> you say import are you importing records from an old built data-source? >>> >>> On Tue, Oct 13, 2015 at 9:55 PM, David McDonald <dave...@gmail.com> >>> wrote: >>> >>>> Yes, I agree I just didn't want to have to create an additional model >>>> for each of these models I would be importing and everything that would go >>>> with that. I think what would likely work is I can create a table in >>>> between my application table and the table I'm importing data from. On >>>> that table I could add a column that I can note records that are invalid. >>>> Then I can create a new action on my controller that reads those to a view >>>> in which I can them send them to the model's _form.html.erb for the user to >>>> correct and attempt to save. >>>> >>>> On Tuesday, October 13, 2015 at 4:46:17 PM UTC-4, mode-x wrote: >>>>> >>>>> Generally speaking i think you should NOT just allow invalid records >>>>> AT ALL. For the record to be saved the user MUST ENSURE that the relevant >>>>> information are valid. >>>>> >>>>> On Tue, Oct 13, 2015 at 9:30 PM, David McDonald <dave...@gmail.com> >>>>> wrote: >>>>> >>>>>> I'm currently trying to setup daily processes that will import >>>>>> information into my database. I have many records that fail validations, >>>>>> and for the most part I have methods that attempt to auto-correct them >>>>>> and >>>>>> re-save, but there are some more complex scenarios that require a user to >>>>>> correct some information before they're valid. I'm trying to come up >>>>>> with >>>>>> a good way in which I can set this up and I've come up with two methods, >>>>>> but I'm not sure which I should really go with... >>>>>> >>>>>> *Scenario 1:* >>>>>> >>>>>> I figure I could import into my models like I normally do, and when >>>>>> they don't pass validations then I will go ahead and save them to the >>>>>> database anyways and then flag them with a boolean column as "invalid". >>>>>> Then I'll setup an action and view to allow the user to see and correct >>>>>> all >>>>>> the records that have been flagged. >>>>>> >>>>>> *Pros:* The pro to this method is I don't have to create various new >>>>>> models/tables for each model that I'm importing into for temporary >>>>>> storage. >>>>>> *Cons:* I'm still storing bad data in the table, and also would have >>>>>> to alter many queries to filter out invalid records based on the boolean >>>>>> column I would add to the model. >>>>>> >>>>>> *Scenario 2:* >>>>>> >>>>>> I create new models that mimic the model that I want to import the >>>>>> records into... but then I'm adding alot of logic that is shared between >>>>>> the two -- not to mention I have a lot of additional files and code. >>>>>> However, this method wouldn't have me storing invalid data in my tables. >>>>>> >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Ruby on Rails: Talk" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to rubyonrails-ta...@googlegroups.com. >>>>>> To post to this group, send email to rubyonra...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/rubyonrails-talk/41a66ff1-2a65-45cc-b6bb-09f7aa57bfa4%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/rubyonrails-talk/41a66ff1-2a65-45cc-b6bb-09f7aa57bfa4%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ruby on Rails: Talk" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to rubyonrails-ta...@googlegroups.com. >>>> To post to this group, send email to rubyonra...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/rubyonrails-talk/b69a71a6-1e81-4d11-b8be-3c146fd7e550%40googlegroups.com >>>> <https://groups.google.com/d/msgid/rubyonrails-talk/b69a71a6-1e81-4d11-b8be-3c146fd7e550%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-talk+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-talk@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rubyonrails-talk/fe10465e-504e-47d2-a77a-90c456aacdbf%40googlegroups.com > <https://groups.google.com/d/msgid/rubyonrails-talk/fe10465e-504e-47d2-a77a-90c456aacdbf%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAHewxcESQCAU6GB8uenHpmqcZS55nRsvjz8ez4no_Kf1ZW7Cxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
