Не совсем понимаю, что мешает делать выдержку меньше при 24 кадрах в секунду? Ведь ни что не заставляет делать выдержку совсем не 1/24 секунды на каждый кадр
В общем я для себя вопрос апдейта решил следующим образом.
псевдокод:
public void Update(Entity entity)
{
using(MyDataContext dc = DataContextFactory.CreateInstance())
{
Entity original = dc.Entities.SingleOrDefault(c => c.Id == entity.Id);
ItemHelper.Clone(entity, original);
dc.SubmitChanges();
}
}
Фишка тут в методе Clone. Он с помощью рефлексии проходтся по всем полям первого объекта, помеченым атрибутом Column и копирует их значени во второй объект.
Для простых апдейтов работает замечательно
наконец-то, давно ждал и не понимал почему до чих пор не сделали.
было бы супер если бы он прокладывал маршрут с учетом пробок и все бы это работало еще и на мобильнике
Есть у меня один приятель. Писал он логгер для одной большой системы, который скидывал различные записи в файл.
так вот алгоритм открытия файла у него выглядел следующим образом:
// Псевдокод:
while(!file.Open())
{
// Подождем еще немножко
thread.Sleep(1000);
}
P.S. Комментарий в коде выглядел именно так, как привел его я :)
Мне кажется проблема в несоответствии возможностей фреймворка и требований к системе. Нельзя написать универсальный фреймворк для всего. Стоит начать с простого и, возможно, таким его и оставить.
К примеру у нас есть простенький фреймворк для работы с данными, который используется уже несколько лет без изменений.
Удобная штука.
Вот бы еще размер порции загружаемых фотографий увеличить. Я уже битый час пытаюсь залить один альбом. Приходится делать это маааленькими кусочками :(
Странный подход, чреватый тормозами при работе ... гарбиджколлектора, как вы его называете, а так же при выборках из таблиц, где присутствуют ненужные данные
В Вашей табличке для связей объектов идентификаторы не являются внешними ключами и теоретически могут ссылаться на несуществующие объекты.
Может возникнуть ситуация несогласованности данных что приведет к проблемам в работе кода.
Если честно, я бы сделал немного по другому.
Cделал бы "базовую" таблицу
ConnectableItem, содержащую 2 поля: Id и Type
далее все таблицы, предполагающие связи ссылаются на эту таблицу таким образом что их первичный ключ так же является и внешним.
+ делается табличка для связей ConnectableItem to ConnectableItem.
Получится более типизированно и исключит возможность появления "кривых" данных.
spiritofsim.livejournal.com/4160.html
К тому же клонирование для ссылочных типов как раз рекомендуется, дабы случайно не изменить объект
псевдокод:
public void Update(Entity entity)
{
using(MyDataContext dc = DataContextFactory.CreateInstance())
{
Entity original = dc.Entities.SingleOrDefault(c => c.Id == entity.Id);
ItemHelper.Clone(entity, original);
dc.SubmitChanges();
}
}
Фишка тут в методе Clone. Он с помощью рефлексии проходтся по всем полям первого объекта, помеченым атрибутом Column и копирует их значени во второй объект.
Для простых апдейтов работает замечательно
как сделать UpdateCheck.Never для всех сущностей по умолчанию?
Уж сколько раз писали про эти грабли.
1. DataBaseCore.DbModel m = new DataBaseCore.DbModel();
Наверное стоит все же засунуть в using
2. p.User = (from usr in m.User where usr.Id == UserId select usr).First();
лучше заменить на
p.User = m.User.SingleorDefault(...);
было бы супер если бы он прокладывал маршрут с учетом пробок и все бы это работало еще и на мобильнике
так вот алгоритм открытия файла у него выглядел следующим образом:
// Псевдокод:
while(!file.Open())
{
// Подождем еще немножко
thread.Sleep(1000);
}
P.S. Комментарий в коде выглядел именно так, как привел его я :)
К примеру у нас есть простенький фреймворк для работы с данными, который используется уже несколько лет без изменений.
Вот бы еще размер порции загружаемых фотографий увеличить. Я уже битый час пытаюсь залить один альбом. Приходится делать это маааленькими кусочками :(
Для написания некоторых букв придется делать довольно крутые повороты, на скорости в которые не войдешь :)
Может возникнуть ситуация несогласованности данных что приведет к проблемам в работе кода.
Cделал бы "базовую" таблицу
ConnectableItem, содержащую 2 поля: Id и Type
далее все таблицы, предполагающие связи ссылаются на эту таблицу таким образом что их первичный ключ так же является и внешним.
+ делается табличка для связей ConnectableItem to ConnectableItem.
Получится более типизированно и исключит возможность появления "кривых" данных.
VS, к примеру, тоже свой собственный веб сервер имеет