Has_one :recording, as: :recordable, inverse_of: :recordable, touch: trueĭelegated_type :recordable, types: Recordable::TYPES, inverse_of: :recordingĪfter_commit :update_recordable, on:
Basecamp 3 video how to#
What I cannot yet figure is how to create a relationship from a Recordable, which can be anything, to a Recording. Record child, parent: recording, status: status, creator: creator Recordings.create!(options).tap do |recording| rge!(recordable: recordable, parent: parent, creator: creator) Yes, Basecamp has something along the lines of: def record(recordable, children: nil, parent: nil, creator: Current.person, **options) So that's where I left things so far, I'll have another look later but I thought you guys my have some interesting insights! Reply They should be recordables but children is used for recording descendants. I'm not sure what the children are supposed to be. It doesn't feel like there's a lot less to do.Īnother thing I don't get is the children association part in the record method that you see here. My understanding is that they don't have to copy the immutable objects, but they still have to duplicate the whole tree of recordings (the recording that points to the copied object as well as any of its descendants - other recordings that point to immutable objects related to the copied object), and they also need to duplicate things associated to the recording such as events or subscribers. They don't need a background job anymore to copy everything, but I don't really get why it's so much faster. Now in this video, here there's a mention that copying is a lot faster thanks to this pattern. So instead of having multiple models sharing the same concerns and attributes, you have the Recording model that takes care of all of that (and that's a lot of something as you saw above, in ).Īny content user-created (Document, Todo, Todolist, etc.) is immutable: instead of updating it, they create a new version, and the recording points to that new version while you get to keep a track of the changes thanks to the Event class. Has_many :children, class_name: 'Recording', foreign_key: :parent_idĭelegated_type : recordable, types: %w class Recording < ApplicationRecordīelongs_to :parent, class_name: "Recording", optional: true The core looks something like this, but you can see a glimpse of it here (lots of things are hidden within the concerns, such as the parent/children that must live in the Tree concern).
It relies on a subpattern that is now part of rails, delegated types:, but there's also a notion of tree structure (recordings belong to other recordings) and of versioning/activity (there's an Event class involved as you can see here ).
Basecamp 3 video software#
You can find breadcrumbs in the "On Writing Software Well" video series ( ) and a bit more details in this presentation ( ). Has anyone tried to unravel the recording pattern used in Basecamp 3 ?
0 kommentar(er)
