Муки создания Ъ кода

Чего только не найдешь в чужий «камментах»:

#задача: узнать о сущности все по ее имени.
# пусть есть такое описание сущности:
# сотрудник
# является человеком
# принадлежит должности (собсно, занимает должность, но переформулируем в целях ясности)
# принадлежит отделу (собсно, работает в отделе, но переформулируем в целях ясности)
# имеет много документов (в смысле, есть сколько-то документов, которые ему принадлежат
# а еще у него есть рейтинг
# получаем на вход нечто вида
#employee: {
# post: 15,
# department: 12,
# person: 3,
# rating:0,
#}
#или вида
#employee: {
# rating:0,
# post: {
# name: 'камерческий деректор',
# rank: 2
# },
# department: {
# name: 'камерция'
# },
# person: {
# name: 'Вася'
# }
#}
# посмотрев на это внимательно, понимаем, что сохранение не самое страшное.
# а вот как этот же камерческий директор Вася должен выглядеть, если мы отдаем его на редактирование
#employee: {
# _id: 200,
# _belongs_to_:['post', 'department'],
# _has_many_:['document],
# _is_:['person'],
# post: 15,
# department: 13
# person: 3
# rating:0
#}
#что можно переформулировать так:
#Employee:{
# _belongs_to_:['Post', 'Department'], # отсюда мы узнаем, что post и department в форме должны быть представлены как комбобоксы выбора объектов
# _has_many_:['Document], # тут по обстоятельствам - можно вывести грид с кнопой «добавить документ»
# _is_:['Person'], # все, что относится к сотруднику как к человеку, следует вывести отдельным филдсетом
# _own_attributes_:['rating'] # а это чиста поля, просто выводим их в основном филдсете формы
#}
#{
# model: 'Employee',
# data: {
# _id: 200,
# _model:'Employee',
# post: 15,
# department: 13
# person: 3,
# rating:0
# }
#}
#и тогда обратно на вход получаем
#{
# model: 'Employee',
# data: {
# _id: 200,
# _model:'Employee',
# post: 11,
# department: 13
# person: 3,
# rating:3
# }
#},
# типа Васю повысили и вынесли благодарность за ударное пинание хуя
# или
#{
# model: 'Employee',
# data: {
# _id: 200,
# _model:'Employee',
# post: 11,
# department: 13
# person: {
# model: 'Person',
# data:{
# _id:3,
# name: 'Лена' # эх, Вася-Вася....
# }
# },
# rating:3
# }
#},
# типа Вася на самом деле Лена
#(тут как-то само собой разумеется, что сущности пишутся СоВсехБольшихБукв, а ссылки на конкретные экземпляры сущностей - маленькими_буковками_через_подчеркивания)
#почему для такой поеботы нельзя использовать django-orm?
#потому что на уровне метаданных эта хрень не различает глаголы «быть» и «принадлежать»
# todo додумать, ибо что-то начинает вырисовываться.



###############################################################################

#нет хуже занятия, чем думать.

#вот честно - сидишь и паришься, хули в шестой раз вместо нормального красивого медиатора получается жопа с ручкой, и от этого
# так писец херово, что хочется пойти и почитать твиттер.

#тут смотри какая жопа - все орм рассчитаны на то, что с ними работает кто-то, кто знает про них все.
# а мне нужна такая прослойка между орм и аппликухой, чтобы аппликуха про конкретику орм ни хуя не знала. и могла спросить
# «а что у вас есть?», «перечислите ваши родоплеменные обычаи, класс А?», «кто ваши дети, инстанс Б?»,
# «как зовут вашу левую руку, класс Ж?», «можно мы пришьем вам вместо хуя щупальце, а из вашего хуя сделаем
# тентакль для Ю, инстанс Ы?» и все в таком духе.

#короче, плод инцеста горной ведьмы, обезьяны, паттерна «медиатор» и маттерна «метадата».

#шестой раз переписываю - и все равно орм получается, эта штука норовит оттянуть на себя чисто ормовские задачи,
# типа инсертов и прочего круд.

#шесть раз рисовал.

#на листочке детали не помещаются, а дьявол в деталях.

#вопрос - почему не взять орм, в которой что-то из этого уже есть, а остальное туда дописать, и писец?

#а потому что, например, даже самые продвинутые питоновские орм на уровне данных не делают различия между
# наследованием и принадлежностью.

#в принципе, так оно и есть - сказать, что сотрудник есть человек, на уровне базы значит, что в таблице сотрудников есть ссылка
# на таблицу людей, и не просто так, а уникальная в пределах таблицы.

#но мне-то, блядь, эти две ситуации надо совершенно по-разному разруливать на уровне аппликухи.

#когда сотрудник есть человек - надо выводить в форме дополнительный филдсет, а когда у сотрудника есть должность - вывести
# для нее один только комбик в основном филдсете, и гуд.

#но, блджад, ни хуя - стоит полезть в метаданные сотрудника, выяснится, что у него есть человек и должность.

#или, к примеру, есть человек, хотим сделать из него сотрудника.

#говно вопрос, говорим мы, создаем пустой инстанс сотрудника и говорим ему, что вот этот вот инстанс человека - его персональные
# папа и мама.

#это ни хуя не является проблемой, если мы знаем, что есть такие, блядь, сотрудники, которые одновременно человеки - в смысле,
# если говорить философским языком времен Аристотеля, есть категория «сотрудник», каждый элемент которой состоит
# в родственных отношениях с одним и только одним элементом категории «человек», обратное неверно.

#но мне, блядь, нужно сказать это на языке Кантора - для любого А существует ровно один Б, и все это однозначно описывается
# тройкой ({А}, {Б} и f), где f сюрьективна, вне зависимости от конкретной природы А и Б.

#то есть, мне на вход поступает нечто, и я должен узнать, что это нечто называется «человек», что оно может быть еще и «сотрудник»,
# не имея понятия ни о людях, ни о трудовом кодексе.

#ни в каком орм так сделать не получится, потому что это не задача орм.

#задача орм - записывать данные о конкретных сущностях с конкретными именами, а не заниматься сюрьекцией
# и прочими онтологиями.