On Sunday, January 25, 2015 at 8:50:07 PM UTC-5, Matt jones wrote:
>
>
> On Jan 25, 2015, at 3:42 PM, Maxim Chernyak <madfa...@gmail.com 
> <javascript:>> wrote: 
>
> > When using STI, if you introduce a new subclass in a git branch, then 
> create a db record while in it, then switch to another branch, you will get 
> uninitialized constant error when trying to query those records. Certain 
> kinds of applications (like ours) could run into this a lot, so I'm 
> wondering if there could be a null-object-patternish solution to this. E.g: 
> > 
> > * Accept proc for inheritance_column, which evaluates on instances, with 
> type passed as an arg to it, and whatever it returns becoming the record in 
> that case. This way we can plug those records with some placeholders 
>
> The proc can’t be run on an instance - the error is arising when AR tries 
> to determine what class to use. The calling context is in find_sti_class: 
>

Sorry I accidentally left that confusing "evaluates on instances" in there, 
noticed after hitting send, I meant everything besides that; i.e. it gets 
passed the type value, no model instances involved.
 

> > * Add option self.ignore_unknown_types = true to activerecord to simply 
> auto-rescue + skip records with uninitialized constant error (perhaps print 
> a warning instead) 
>
> It’s not clear to me what “skipping” a record in this scenario would mean. 
> If I have a model that belongs_to an instance of the missing class, what do 
> I get back when I access it? `nil`? `RecordNotFound` exception? If I have a 
> validation that requires the presence of that missing object, does `save` 
> still work? 
>
> There are plenty more questions like those. “Muddling through” with bad 
> data is almost certainly going to break something upstream in people’s 
> applications - something considerably harder to troubleshoot than a 
> straightforward `SubclassNotFound` error on loading a bad record. 
>

While you're right about this being a can of worms, I was trying to think 
of a way to piggyback on existing fully defined behavior, like "pretend 
record is not in database, and everything that implies. End of story"
 

>
> As to the “sample data” issue, if it’s worth keeping in the DB it’s worth 
> keeping in source control. If writing a db/seeds.rb file is too complicated 
> (maybe you’re importing large datasets from elsewhere), I’d recommend 
> things like YamlDb to make repeatable seed data. Even `mysqldump > 
> sample_data.sql` is a start… 
>

We have very image-heavy application, and it's not ideal to have big 
payloads of files dragged around in the repo, but it's not the end of the 
world either. There are certainly all kinds of workarounds, but this 
feature seemed reasonable to bring up, so here I am.
 

>
> —Matt Jones 
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to