OpenNeo/impress
OpenNeo/impress
1
0
Fork 1
Code Pull requests Activity
impress/app/models/parent_swf_asset_relationship.rb

27 lines
525 B
Ruby
Raw Permalink Normal View History

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
Revert modeling refactors to the old modeling that worked! Because we ended up with such a big error, and it doesn't have an easy fix, I'm wrapping up today by reverting the entire set of refactors we've done lately, so modeling in production can continue while we improve this code further over time. I generated this commit by hand-picking the refactor-y commits recently, running `git revert --no-commit <hash>` in reverse order, then manually updating `pet_spec.rb` to reflect the state of the code: passing the most important behavioral tests, but no longer passing one of the kinds of annoyances I *did* fix in the new code. ```shell git revert --no-commit 48c1a58df9a170a2d9ad213f5424fda91177fcba git revert --no-commit 42e7eabdd8fb8640dd71c38b42a1b515ec572dfd git revert --no-commit d82c7f817ae43f95db473b6d3c66bae53b16ae00 git revert --no-commit 5264947608c81176320981e9bccd9b02f2089db6 git revert --no-commit 90407403baf0b504fca99fe3a9a6a90ed8b9a66d git revert --no-commit 242b85470d1e5e161f2a49c16faaad38f052b74f git revert --no-commit 9eaee4a2d4cdf1a956c3710a3a307e8f0c383ecb git revert --no-commit 52ca41dbff4c08165012afa774677c938bdfcaf3 git revert --no-commit c03e7446e3d5e1323414039555d11a76abce2efe git revert --no-commit f81415d3270e7bfee17101475c8b98b79e32fde1 git revert --no-commit 13ceec8fcc866fcc0a81e86a74b6e79b5f7d4f6c ```
2024-11-06 14:31:16 -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
Revert modeling refactors to the old modeling that worked! Because we ended up with such a big error, and it doesn't have an easy fix, I'm wrapping up today by reverting the entire set of refactors we've done lately, so modeling in production can continue while we improve this code further over time. I generated this commit by hand-picking the refactor-y commits recently, running `git revert --no-commit <hash>` in reverse order, then manually updating `pet_spec.rb` to reflect the state of the code: passing the most important behavioral tests, but no longer passing one of the kinds of annoyances I *did* fix in the new code. ```shell git revert --no-commit 48c1a58df9a170a2d9ad213f5424fda91177fcba git revert --no-commit 42e7eabdd8fb8640dd71c38b42a1b515ec572dfd git revert --no-commit d82c7f817ae43f95db473b6d3c66bae53b16ae00 git revert --no-commit 5264947608c81176320981e9bccd9b02f2089db6 git revert --no-commit 90407403baf0b504fca99fe3a9a6a90ed8b9a66d git revert --no-commit 242b85470d1e5e161f2a49c16faaad38f052b74f git revert --no-commit 9eaee4a2d4cdf1a956c3710a3a307e8f0c383ecb git revert --no-commit 52ca41dbff4c08165012afa774677c938bdfcaf3 git revert --no-commit c03e7446e3d5e1323414039555d11a76abce2efe git revert --no-commit f81415d3270e7bfee17101475c8b98b79e32fde1 git revert --no-commit 13ceec8fcc866fcc0a81e86a74b6e79b5f7d4f6c ```
2024-11-06 14:31:16 -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
Copy permalink