Re: [Rails-core] Graceful handling of missing STI constants
On Jan 26, 2015, at 11:49 AM, Jason Fleetwood-Boldt t...@datatravels.com wrote: If I were you I’d stub out all the different objects with ‘shell’ implementations in your master branch, and then AR won’t blow up when it tries to instantiate the objects. Then you can leave implementation details to the branches where you want to implement/test them. Yeah, this is one of a few possible workarounds, but very inconvenient for us. Are all those objects different from eachother? (That is, do they each implement a certain domain logic that can best be implemented with Ruby code). Yes, that's exactly the case. On Jan 26, 2015, at 6:24 AM, Xavier Noria f...@hashref.com mailto:f...@hashref.com wrote: You're facing one possible way to have incompatible schemas between branches. Divergence in Git branches is an external issue, and should be solved where it is originated in my view, at the workflow level. If your application has a very specific use case for STI it could be the case that your most efficient way to workaround it is by monkey patching something in AR... that depends on the details. But certainly I don't see the solution builtin in AR. Is it really an “incompatible schema”-type problem when in fact it’s certain db records (data) that cause errors, not the schema itself? The way I see this: rails has default behavior for dealing with type column (it constantizes it), and this behavior could be easily swapped if given a hook. However, your main argument (i.e. it’s a workflow problem) does sound pretty convincing, especially given the vibe I’m getting that I’m the only one who needs this so far, so I don’t want to impose. -- 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.
Re: [Rails-core] Graceful handling of missing STI constants
If I were you I’d stub out all the different objects with ‘shell’ implementations in your master branch, and then AR won’t blow up when it tries to instantiate the objects. Then you can leave implementation details to the branches where you want to implement/test them. Also it seems odd to me that you have a workflow that consistently creates new objects that will rely on STI implementations. Are all those objects different from eachother? (That is, do they each implement a certain domain logic that can best be implemented with Ruby code). If the answer is no, I’d question whether or not STI is the right pattern for what you are doing. -Jason On Jan 26, 2015, at 6:24 AM, Xavier Noria f...@hashref.com wrote: You're facing one possible way to have incompatible schemas between branches. They are created by workflows external to Active Record, to me it doesn't makes sense that Active Record acts in a way it is not supposed to, to address divergences in Git branches. Divergence in Git branches is an external issue, and should be solved where it is originated in my view, at the workflow level. If your application has a very specific use case for STI it could be the case that your most efficient way to workaround it is by monkey patching something in AR... that depends on the details. But certainly I don't see the solution builtin in AR. -- 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.
Re: [Rails-core] Graceful handling of missing STI constants
You're facing one possible way to have incompatible schemas between branches. They are created by workflows external to Active Record, to me it doesn't makes sense that Active Record acts in a way it is not supposed to, to address divergences in Git branches. Divergence in Git branches is an external issue, and should be solved where it is originated in my view, at the workflow level. If your application has a very specific use case for STI it could be the case that your most efficient way to workaround it is by monkey patching something in AR... that depends on the details. But certainly I don't see the solution builtin in AR. -- 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.
Re: [Rails-core] Graceful handling of missing STI constants
On Jan 25, 2015, at 3:42 PM, Maxim Chernyak madfanc...@gmail.com 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: https://github.com/rails/rails/blob/6d72485b6977804a872dcfa5d7ade2cec74c768e/activerecord/lib/active_record/inheritance.rb#L169 a class method defined on ActiveRecord::Base. At runtime, this will have access to the class that `find` was called on (presumably the STI base class) and the value from the inheritance column. Returning a fully-initialized object from here would require skipping a bunch of code in `instantiate`. * 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. 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… —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. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Rails-core] Graceful handling of missing STI constants
Why not just use different databases in your different git branches? On Sun, Jan 25, 2015 at 3:42 PM, Maxim Chernyak madfanc...@gmail.com 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 * Add option self.ignore_unknown_types = true to activerecord to simply auto-rescue + skip records with uninitialized constant error (perhaps print a warning instead) Only to be used in dev/staging of course. Any thoughts? -- 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. -- 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.
[Rails-core] Graceful handling of missing STI constants
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 * Add option self.ignore_unknown_types = true to activerecord to simply auto-rescue + skip records with uninitialized constant error (perhaps print a warning instead) Only to be used in dev/staging of course. Any thoughts? -- 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.
Re: [Rails-core] Graceful handling of missing STI constants
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.
