Add API for setting messages via ActiveRecord Relations

[raghubetina]

Summary

• Implements messages= method that accepts arrays or ActiveRecord::Relations
• Adds support for custom attribute mappings via configure_attributes
• Handles images via direct attributes or associations
• Updates README with documentation and examples
• Adds comprehensive tests

Test plan

• Run the existing test suite: bundle exec rspec
• Test with the new specific tests: bundle exec rspec spec/ai/chat/messages_assignment_spec.rb

---

Important

Adds messages= method to AI::Chat for setting messages with arrays or ActiveRecord::Relations, supporting custom attribute mappings and image handling.

• Behavior:
  • Adds messages= method in chat.rb to accept arrays or ActiveRecord::Relations for setting messages.
  • Supports custom attribute mappings via configure_attributes method.
  • Handles images in messages through direct attributes or associations.
• Documentation:
  • Updates README.md with examples and documentation for new messages= method and custom attribute mappings.
• Testing:
  • Adds messages_assignment_spec.rb with tests for messages= method, covering arrays, ActiveRecord objects, and custom mappings.

^{This description was created by for d8ef894. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to d8ef894 in 2 minutes and 8 seconds. Click for details.

• Reviewed 361 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 7 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. README.md:172

• Draft comment:
  The updated instructions and examples for setting messages (including with ActiveRecord relations and images) are clear and comprehensive.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

2. lib/ai/chat.rb:281

• Draft comment:
  The new messages= setter method is well-structured and uses the attribute mappings correctly. Consider validating that the extracted role is present to avoid potential nil cases.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

3. spec/ai/chat/messages_assignment_spec.rb:1

• Draft comment:
  The tests comprehensively cover different scenarios (string keys, images, multiple images, custom attribute mappings, and ActiveRecord-like objects). Great job!
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. README.md:175

• Draft comment:
  The updated documentation clearly illustrates how to set messages using arrays, AR relations, and image handling. Ensure consistency with custom attribute mapping examples.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

5. lib/ai/chat.rb:285

• Draft comment:
  Consider verifying that new_messages is enumerable (e.g. responds to :each) to avoid runtime errors if nil or an invalid type is passed.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

6. lib/ai/chat.rb:321

• Draft comment:
  For unknown role values, messages are added without validation. Consider raising an error or logging a warning to avoid silent failures from unrecognized roles.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The code appears to intentionally handle unknown roles in a flexible way, allowing for future role types or custom roles. The current behavior of normalizing the format (ensuring symbol keys) while preserving the role value seems deliberate. Adding validation could make the code more restrictive than intended. The comment suggests making the code more defensive but may go against the design goal of flexibility. I could be wrong about the intention - maybe unknown roles should be rejected. The flexible handling could mask bugs where role names are misspelled. The code shows clear intent to handle unknown roles gracefully through careful normalization. If role validation was desired, it would likely have been implemented alongside the explicit handling of "system", "user" and "assistant" roles. The comment should be deleted as it suggests adding restrictions that appear to go against the intentionally flexible design of the code.

7. spec/ai/chat/messages_assignment_spec.rb:180

• Draft comment:
  Please add a newline at the end of the file for POSIX compliance.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While having a newline at the end of files is indeed a best practice, this kind of formatting issue is typically handled by automated tools like linters or EditorConfig. It's a very minor issue that doesn't affect functionality and would likely be caught by CI/CD pipelines if it was important to the project. The comment is technically correct - POSIX standards do recommend ending files with newlines. This could cause issues with some tools. However, this is exactly the kind of minor formatting issue that should be handled by automated tools rather than manual code review comments. It adds noise to the review without providing significant value. While technically correct, this comment should be removed as it's too minor for manual code review and better handled by automated tools.

Workflow ID: wflow_3pff7XIkWhpPURA7

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}