Да, тут мне уже ответили аналогично: djbook.ru/forum/topic/389/#post-14984
Жаль, думал не придётся заниматься переопределением этой модели, и всего из-за какой-то строки, которую можно было бы вынести в опции
Ну, как помнится, там конечно не двумя строками кода делается это, вроде какой-то паттерн реализуется. Вы его костылём называете? В то время как космические кор.. приложения большинства разработчиков в Play бороздят наши с вами мобильные устройства с помощью нативного SQLite?)
Московские чуваки делали) Можно и обратиться, но только с более конструктивной формулировкой, копипастить куски кода из проекта они вряд ли будут, но на путь направить могут
@killla, причем в google это отлично понимают, и скупают такие компании, хотя обычно их покупки направлены на расширение сфер их присутствия, чем просто на банальное поглощение конкурентов :-)
@Assargin, в конечном счете, вам же важен выбранный город, зачем давать возможность вообще выбирать область и страну? А если и давать - то как обычно в инете делают: сначала выбираешь страну, потом область, потом город.. Вы, как я понял, хотите уйти от этого способа? Посмотрите, в общем, как сделано в ВК, с точки зрения юзабилити - мне норм.
@eprivalov, можете при вводе города показывать не только названия найденных городов, но и их область и страну, как это сделано в ВК: joxi.ru/Hk1CUxjKTJCQOAxc_Jw
@eprivalov, я бы крепко подумал перед тем как делать так, как вы описали. Я конечно не знаю всех деталей и для чего вы это делаете, но городов "Александровка" в стране дай бог по одному в каждой области, какой будете возвращать?)
Тут не подскажу, сам давно использую иннодб, а когда мне в прошлом году встала задача справляться с нагрузками по выборкам (поиску) - я начал использовать sphinx для этого, и все
Да ну как сказать, я делал тысячи запросов в пределах одной транзакции, в память так и не уперся, но было требование слишком долго не удерживать блокировку и открытую транзакцию. Поэтому разбил одну большую операцию на мелкие, не потеряв существенно в производительности.
Один раз даже пришлось реально использовать уровни изоляций транзакций. В системе перелинковки, при длительной операции привязки тысяч ссылок на страницы необходимо было в веб-морде сделать так, чтобы уже занятые страницы (к которым я в БД в таблице ссылок привязал ссылки) не учитывались при поиске свободных страниц. И так как транзакция размещения ссылок еще была открыта, использовал при выборке данных для веб-морды уровень read uncommitted - чтение "грязных" данных, тогда как по умолчанию уровень read committed - пока транзакция открыта (не закоммичена и не откачена), её изменения другие транзакции не видят.
Ну и как, получше с транзакциями стало?
Блокируется не вся БД, а то ли таблица, то ли даже строки (скорее всего, точно сейчас не могу сказать). На эту тему можно почитать в инете, и еще можно почитать про уровни изоляций транзакций.
Если слишком большой импорт, можете не весь импорт оборачивать в транзакцию, а, скажем, строк 1000. Или использовать вставку сразу нескольких строк (insert into tt (...) values (...),(...),(...))
Жаль, думал не придётся заниматься переопределением этой модели, и всего из-за какой-то строки, которую можно было бы вынести в опции