Hi all,

I've recently started working on a project that uses Mongoid and we're interacting with data that's also accessed by other projects (primarily written in Java and Python). After some discussion (before my involvement), it was determined that 'foreign keys' to associate this data would be used but that they'd be stored as strings instead of native ObjectIds. I fully understand the implications including storage space, lookup speeds, etc. However, this is the path that's been chosen and I have to continue down this path.

Currently, there's "all-or-nothing" settings for Mongoid to use strings vs ObjectIds for their data; however, I was looking to customize behavior for belongs_to and has_many relationships (and only certain ones at that, not all) so that only certain ones would use strings (and behave correctly from both directions. I have two questions: 1) is this possible currently with minimal monkey-patching? I've found that adding a field :association_id after the belongs_to works fine for that direction but the has_many still doesn't work (assuming it's looking at the document's _id, recognizing it's an ObjectId, and querying with that type instead of casting to a string) 2) if I create a pull request, would this be accepted (assuming there are tests, etc.)?

Again, I understand that this is not the ideal way to use mongo (or mongoid) but I've a problem to solve and I'd like to continue using mongoid in a non-hacky manner. Thanks for any insight!

UPDATE: Declaring field :association_id after a belongs_to does, in fact, cast properly when coming from the opposite direction (a has_many).