Вы думаете, что выгодно переключиться на Платформу Объекта? [закрытый]
Попробуйте:
DT = data.table(col1 = 1:3)
colname = "col1"
DT[, colname, with = FALSE] # select
# col1
# 1: 1
# 2: 2
# 3: 3
DT[, (colname) := 4:6] # assign
# col1
# 1: 4
# 2: 5
# 3: 6
Последний известен как столбец plonk , потому что вы заменяете весь вектор столбца ссылкой. Если подмножество i присутствует, оно будет переназначать по ссылке. Параны вокруг (colname) - это стенография, представленная в версии v1.9.4 на CRAN Oct 2014. Вот новость:
Using `with = FALSE` with `:=` is now deprecated in all cases, given that wrapping
the LHS of `:=` with parentheses has been preferred for some time.
colVar = "col1"
DT[, colVar := 1, with = FALSE] # deprecated, still works silently
DT[, (colVar) := 1] # please change to this
DT[, c("col1", "col2") := 1] # no change
DT[, 2:4 := 1] # no change
DT[, c("col1","col2") := list(sum(a), mean(b)] # no change
DT[, `:=`(...), by = ...] # no change
См. Также раздел «Подробности» в ?`:=`:
DT[i, (colnamevector) := value]
# [...] The parens are enough to stop the LHS being a symbol
И чтобы ответить на дальнейший вопрос в комментарии, вот один из способов (как обычно, существует много способов):
DT[, colname := cumsum(get(colname)), with = FALSE]
# col1
# 1: 4
# 2: 9
# 3: 15
или вам может быть проще читать, писать и отлаживать только до eval a paste, аналогично построению динамического оператора SQL для отправки на сервер:
expr = paste0("DT[,",colname,":=cumsum(",colname,")]")
expr
# [1] "DT[,col1:=cumsum(col1)]"
eval(parse(text=expr))
# col1
# 1: 4
# 2: 13
# 3: 28
Если вы делаете это много, вы можете определить вспомогательную функцию EVAL:
EVAL = function(...)eval(parse(text=paste0(...)),envir=parent.frame(2))
EVAL("DT[,",colname,":=cumsum(",colname,")]")
# col1
# 1: 4
# 2: 17
# 3: 45
Теперь, когда data.table 1.8.2 автоматически оптимизирует j для эффективности, может быть предпочтительнее использовать метод eval. get() в j предотвращает некоторые оптимизации, например.
Или существует set(). Низкая накладная, функциональная форма :=, которая была бы прекрасна здесь. См. ?set.
set(DT, j = colname, value = cumsum(DT[[colname]]))
DT
# col1
# 1: 4
# 2: 21
# 3: 66
8 ответов
IMO, не в данный момент.
Это ясно (от недавние объявления особенно), что EF находится в для некоторых тяжелых изменений как" , thunderdome" сценарий теряет значение между LINQ к SQL и EF. Что бы ни случилось, EF (через несколько лет) будет почти наверняка выглядеть очень отличающимся к EF сегодня. Или конечно "достаточно отличающийся";-p
По сути, мое представление: палка с простым. И простой LINQ к SQL.
я не вижу, что много преимущества изучает известно сложную систему, если я знаю, что оно собирается измениться очень скоро.
И я - 100% с Вами на LINQ к SQL;-p
, Если бы мне были нужны что-то большее чем LINQ к SQL прямо сейчас, я посмотрел бы NHibernate или возможно LLBLGen Pro.
( редактирование - как обновление, мое положение смягчилось немного, здесь и здесь - но я все еще использую LINQ к SQL в качестве своего основного инструмента; также - LINQ-to-SQL еще не довольно мертв ;-p).
Я выполнил несколько проектов MVC, работающих в настоящее время с L2SQL под капотом, и нашел, что им очень приятно пользоваться. Сейчас я начинаю новый проект и решил написать его, используя EF и L2EF, учитывая ранее цитированные статьи, провозглашающие смерть L2SQL. Спустя всего пару дней я решил вернуться к L2SQL. Простые вещи, такие как необходимость установки внешних ключей для вставок с использованием либо ужасного синтаксиса, показанного ниже, либо ненужные поиски, потрясли меня.
foo.Foreign_TypeReference.EntityKey =
new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);
Вместо:
foo.Foreign_Type_Id = ForeignTypeId;
Я не думаю, что будет очень трудно перенести L2SQL на будущую версию EF, поскольку L2SQL имеет подмножество функциональных возможностей (хотя и лучше реализованных) , Несколько вещей, которые есть в L2SQL, которых нет в L2EF, например Single () и SingleOrDefault (), можно перенести в EF, создав несколько методов расширения. Я думаю, что потребуется гораздо меньше времени для запуска системы с использованием L2SQL, а затем перенести ее позже, когда EF не так вонючий.
При выполнении управляемой базой данных разработки EF имеет реальные преимущества сегодня.
я привык и LINQ для SQL и EF и работал через многие небольшие разочарования EF v1.
Однако одна вещь, которая сделала победу EF v1 для меня, удивительно хороша обновление от базы данных мастер. Невероятно, это на самом деле работы ! Это может звучать тривиальным, но если Вы делаете, база данных сначала разрабатывают, Вы хотите полагаться на инструменты для создания классов для Вас, и Вы не хотите должными быть повторно создавать свою всю модель только для внесения изменения.
Это одно делает EF v1 моим выбором. Я предлагаю игнорировать расширенные функции EF v1 - это еще нигде не рядом применимо как амбициозная платформа, которой это имеет целью быть.
Выносивший неуклюжий из EF v1 и Вы будете в лучшем положении для будущего.
Pete.
Я должен согласиться с Марком Гравеллом. Может быть, , когда выйдет следующая версия Entity Framework (.net 4.0 / VS2010), будет ли преимущество в использовании EF, и к тому времени это, вероятно, будет сильно отличаться от текущей версии EF.
До тех пор, по крайней мере, я буду избегать EF, как чумы для чего-либо кроме тестов / экспериментального кода, который никогда не попадет в производство.
Форум EF msdn полон примеров того, почему EF не готов к прайм-тайму, но у меня есть один конкретный пример , который является явным победителем - что будет Обычно простой запрос из пяти таблиц (10-15 строк SQL) становится > 1500 строк SQL при использовании EF и элемента управления EntityDataSource:
http: // forums. microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1
http://paste-it.net/public/q6ed5c2/
А что касается будущего EF - с историей Microsoft об изменении направления в крупных стратегических вещах в одночасье, кто знает, сбудется ли их текущая «стратегическая цель» с EF через пару лет ... ? Я бы точно не поспорил на это. См .:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623
Для записи некоторое колебание о будущем LINQ к SQL было выражено здесь:
LINQ to SQL, по-видимому, не подходит, если вы не используете SQL Server (или SQL Server compact), поэтому для меня было достаточной причиной избежать его и использовать EF (я хотел использовать PostgreSQL).
В v1 EF определенно не хватает вещей, которые заставили бы меня смущаться рекомендовать это. Похоже, что версия 2 EF (когда выйдет) будет первой версией, которую можно было бы серьезно рекомендовать для перехода на.
Довольно много опытных разработчиков дали" Вотум недоверия Платформы Объекта.NET ADO ", как обсужден далее здесь .
я думаю, что мы ожидаем, что он будет значительно улучшен в .Net 4.0 командой ADO.NET.
И вот являются [приблизительно 113] видео от недавнего PDC.
Недавно мне пришлось исследовать, какой проект ORM следует использовать. Сначала - попробовал L2S. Это было совсем не плохо, но уже устарело (MS больше не будет его поддерживать), поэтому я начал проверять L2E. Я в порядке с сгенерированным кодом, но создание поддельных представлений, сущностей и отображений между ними просто для того, чтобы сделать хранимую процедуру доступной, чтобы не заполнять все поля сущностей, было для меня излишним. И я хотел отделить свой слой доступа к данным, поэтому мне пришлось сопоставить данные из сгенерированных объектов с теми, которые я создал.
Мне потребовалось несколько часов, чтобы поэкспериментировать с NHibernate + Fluent NHibernate + LINQ to NHibernate
, чтобы придерживаться этой комбинации.