impress/app/models/parent_swf_asset_relationship.rb

class ParentSwfAssetRelationship < ApplicationRecord
  self.table_name = 'parents_swf_assets'
  
  belongs_to :parent, polymorphic: true
  
  belongs_to :swf_asset

  after_save :update_parent_cached_fields
  after_destroy :update_parent_cached_fields
  
  def item=(replacement)
    self.parent = replacement
  end
  
  def pet_state
    PetState.find(parent_id)
  end
  
  def pet_state=(replacement)
    self.parent = replacement
  end

  def update_parent_cached_fields
    parent.try(:update_cached_fields!)
  end
end
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll! 2023-08-02 16:05:02 -07:00			`class ParentSwfAssetRelationship < ApplicationRecord`
Update to new set_table_name syntax 2023-07-22 12:36:04 -07:00			`self.table_name = 'parents_swf_assets'`
groundwork for preview, swf asset and relationship model 2010-05-16 12:01:38 -07:00
Fix modeling bug where compatible_body_ids field was not updating Ah right, the callbacks in `ParentSwfAssetRelationship` don't get called when Rails does automatic join-model management stuff. We need the `Item` to call its `update_cached_fields` callback itself, too! When fixing this, I found a new bug that arose, in how we infer `body_id` for assets that fit all pets. Fixing that next! 2024-11-06 13:39:32 -08:00			`belongs_to :parent, polymorphic: true`
roulette system :) 2011-01-27 13:35:46 -08:00
give SWFs real, unique ID numbers Lots of scary bugs were being caused by the fact that the possibly-duplicate Neopets ID was being treated as an SWF's real primary key, meaning that a save meant for object swf number 123 could be saved to biology swf number 123. Which is awful. This update gives SWFs their own unique internal ID numbers. All external lookups still use the remote ID and the type, meaning that the client side remains totally unchanged (phew). However, all database relationships with SWFs use the new ID numbers, making everything cleaner. Yay. There are probably a few places where it would be appropriate to optimize certain lookups that still depend on remote ID and type. Whatever. Today's goal was to remove crazy glitches that have been floating around like mad. And I think that goal has been met. 2012-01-12 15:17:59 -08:00			`belongs_to :swf_asset`
Add cached fields to Item model for searching, but don't use them yet This is the first part of a change to improve search performance, by caching occupied zone IDs and supported body IDs onto the Item record itself, instead of always doing joins with `SwfAsset`. It's unfortunate, because part of the power of SQL is joins! But doing joins with big tables, in ways that can't take advantage of indexes in the same ways as we often want to, is… slow. It's possible there's something I'm misunderstanding about SQL optimization, and this _could_ be done with query optimization or indexes instead of duplicating data like this? This complexity carries the risk of data getting out of sync in unforeseen ways. But this is what I know how to do, and it seems to be working, so! Okay! 2024-09-30 23:10:37 -07:00
			`after_save :update_parent_cached_fields`
			`after_destroy :update_parent_cached_fields`
groundwork for preview, swf asset and relationship model 2010-05-16 12:01:38 -07:00
			`def item=(replacement)`
give SWFs real, unique ID numbers Lots of scary bugs were being caused by the fact that the possibly-duplicate Neopets ID was being treated as an SWF's real primary key, meaning that a save meant for object swf number 123 could be saved to biology swf number 123. Which is awful. This update gives SWFs their own unique internal ID numbers. All external lookups still use the remote ID and the type, meaning that the client side remains totally unchanged (phew). However, all database relationships with SWFs use the new ID numbers, making everything cleaner. Yay. There are probably a few places where it would be appropriate to optimize certain lookups that still depend on remote ID and type. Whatever. Today's goal was to remove crazy glitches that have been floating around like mad. And I think that goal has been met. 2012-01-12 15:17:59 -08:00			`self.parent = replacement`
both items, pet types own assets 2010-05-16 17:45:30 -07:00			`end`

pet state models now own assets, not pet types 2010-05-20 18:11:08 -07:00			`def pet_state`
roulette system :) 2011-01-27 13:35:46 -08:00			`PetState.find(parent_id)`
both items, pet types own assets 2010-05-16 17:45:30 -07:00			`end`

pet state models now own assets, not pet types 2010-05-20 18:11:08 -07:00			`def pet_state=(replacement)`
give SWFs real, unique ID numbers Lots of scary bugs were being caused by the fact that the possibly-duplicate Neopets ID was being treated as an SWF's real primary key, meaning that a save meant for object swf number 123 could be saved to biology swf number 123. Which is awful. This update gives SWFs their own unique internal ID numbers. All external lookups still use the remote ID and the type, meaning that the client side remains totally unchanged (phew). However, all database relationships with SWFs use the new ID numbers, making everything cleaner. Yay. There are probably a few places where it would be appropriate to optimize certain lookups that still depend on remote ID and type. Whatever. Today's goal was to remove crazy glitches that have been floating around like mad. And I think that goal has been met. 2012-01-12 15:17:59 -08:00			`self.parent = replacement`
groundwork for preview, swf asset and relationship model 2010-05-16 12:01:38 -07:00			`end`
Add cached fields to Item model for searching, but don't use them yet This is the first part of a change to improve search performance, by caching occupied zone IDs and supported body IDs onto the Item record itself, instead of always doing joins with `SwfAsset`. It's unfortunate, because part of the power of SQL is joins! But doing joins with big tables, in ways that can't take advantage of indexes in the same ways as we often want to, is… slow. It's possible there's something I'm misunderstanding about SQL optimization, and this _could_ be done with query optimization or indexes instead of duplicating data like this? This complexity carries the risk of data getting out of sync in unforeseen ways. But this is what I know how to do, and it seems to be working, so! Okay! 2024-09-30 23:10:37 -07:00
			`def update_parent_cached_fields`
Fix modeling bug where compatible_body_ids field was not updating Ah right, the callbacks in `ParentSwfAssetRelationship` don't get called when Rails does automatic join-model management stuff. We need the `Item` to call its `update_cached_fields` callback itself, too! When fixing this, I found a new bug that arose, in how we infer `body_id` for assets that fit all pets. Fixing that next! 2024-11-06 13:39:32 -08:00			`parent.try(:update_cached_fields!)`
Add cached fields to Item model for searching, but don't use them yet This is the first part of a change to improve search performance, by caching occupied zone IDs and supported body IDs onto the Item record itself, instead of always doing joins with `SwfAsset`. It's unfortunate, because part of the power of SQL is joins! But doing joins with big tables, in ways that can't take advantage of indexes in the same ways as we often want to, is… slow. It's possible there's something I'm misunderstanding about SQL optimization, and this _could_ be done with query optimization or indexes instead of duplicating data like this? This complexity carries the risk of data getting out of sync in unforeseen ways. But this is what I know how to do, and it seems to be working, so! Okay! 2024-09-30 23:10:37 -07:00			`end`
groundwork for preview, swf asset and relationship model 2010-05-16 12:01:38 -07:00			`end`