Plain Text | 95 lines | 95 code | 0 blank | 0 comment | 0 complexity | d7d51efe251865dcdd5d70e35cbb0219 MD5 | raw file
1questions 2 how to name the different relationship types (the ror conventions seem to confuse people) 3destruction 4 destroy_r to destroy all dependant vector fields 5configuration 6 handle loading relationship info from config file (dry) or let the use call the methods directly on both ends 7 check for foreign key and unique constraints that should be present 8 warn if they are not 9 have a way to auto-generate sql statements to fix add them 10 auto-generate a config file or set of relationship method calls 11relationships 12 features 13 lazy loading 14 automatic caching 15 pre-loading via config info 16 pre-loading via a big sql statement 17 ordering or vector objects 18 data sharing when pre-loading both has many and has many through relationships 19 types 20 + has many 21 + has one 22 + belongs to 23 access name 24 local field name 25 remote class 26 remote field name 27 + has many through 28 access name 29 join class or table 30 join class local field 31 join class remote field 32 remote class 33 remote field 34 options 35 access name 36 local field name 37 remote table 38 remote key field 39 remote name field 40 segment (horizontal, some fields in other table, one to one mapping between the two tables) 41 local field name 42 remote table name 43 remote field name 44 partition (vertical, all fields the same in all tables, tables logically unioned together) 45 list of table names 46 partition function 47 tree 48 parent field name 49 nested set 50 init function 51 move function 52 graph 53 adjacency table 54 node1id field 55 node2id field 56 methods 57 count 58 loadAndCount 59 load 60 get 61 iterator methods (for has many and has many through) 62 generate sql 63 loaded 64 clear 65 sqlCount 66 misc 67 maybe move them to be static class data and static methods someday 68 maybe for trees configure to use: 69 adjacency list, 70 adjaceny list with with a stored procedure, (in postgres look at constrib/ltreee connectby) 71 nested sets, 72 nested sets with extra space, 73 nested intervals, 74 binary fractions, 75 materialized path, 76 create as much help for automating nested sets as possible 77 support for special fields such as create_date and update_date 78 should that just be handled in the db? 79 dirty field handling 80 - only update stuff that's changed 81 - four ways to handle saving data 82 - always save all fields all the time 83 - if any field has changed save all fields 84 - save only changed fields 85 - two ways to determine if a field has changed 86 - if they set the value of it for any reason 87 - always load the original value and see if it has changed 88 - diff it with the value from the database 89 - when the object was created 90 - when the field is saved 91 - whenever the field happened to get loaded 92 - when the form was populated 93 - handled it DbObject or in the form handler? 94 - optimistic locking??? 95 - better locking???