Nik Faraday, у вас все вопросы про внедрение, причём характерные для C#. Самой акторной системе всё это абсолютно неважно. В общем случае акторную систему обычно делают синглтоном, но если даже вы будете создавать новую на каждый запрос, ничего не поломается, только расход ресурсов будет выше и акторы в разных системах не смогут между собой общаться без дополнительных приседаний. Как конкретно всё это делается, сильно зависит от используемого IoC-контейнера. Например для Guice есть расширение, которое позволяет сделать так
public SomeConstructor(@Named("some-actor-name") ActorRef someActor) {
...
}
и быть уверенным, что контейнер позаботиться о поиске/создании актора, о внедрении в него необходимых зависимостей и о создании дочерних акторов в контейнере. Естественно, в Spring или compile time DI для Scala всё будет происходить совсем иначе.
gogP, в переменной entry находится ссылка на объект, связанный с полем для ввода длины. Вам надо вызвать метод get этого объекта, который вернёт введëнную в поле строку. А вот уже её можно будет преобразовывать в число.
rPman, прежде всего это идиоматичность. Использование реляционной базы данных подразумевает жёсткую схему БД определённую до рантайма. В очень редких случаях требуется работать в рантайме не с данными, а со схемой, чаще это сигнал плохой архитектуры.
Four4sides, очевидно, нет. Сначала вам придётся минимум год учить какой-то техстек, потом ещё пару лет практиковать свои знания в каком-нибудь реальном коммерческом проекте под руководством опытных профессионалов, и только потом имеет смысл пробовать.
manage.py migrate?