LINQ к SQL -
Я немного погуглил и обнаружил, что django намеревается всегда сохранять в формате UTC в модели, но во время извлечения из db преобразовывается в TIME_ZONE, установленный настройками. ссылка . Так что я полагаю, что есть возможность в формате UTC в экземпляре pre-save. Я могу ошибаться, поскольку у меня нет конкретных сильных знаний об этом.
Я думаю, что это сравнение должно быть сделано в режиме реального времени. Так что теперь совершенно безопасно использовать пользователя TIME_ZONE для сравнения с интервалом from_time. Так что мое предложение
import pytz
import datetime
tz = pytz.timezone('Europe/Sofia')
curtime = tz.localize(datetime.datetime.now())
и преобразовать эту строку кода
if instance.date_time.time() < instance.interval.from_time:
# this returns True when it's meant to return False
в
if curtime < instance.interval.from_time:
# I hope this return False now
14 ответов
Развесьте схему родительской таблицы.
если Вы смотрите здесь, у некоторых других людей была Ваша проблема. http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3493504&SiteID=1
Кажется, что Linq2SQL испытывает затруднения при отображении некоторых внешних ключей на некоторые первичные ключи. У одного парня было разрешение, но я думаю, что Вы уже отображаетесь на столбец IDENTITY.
Так как базу данных не называют, я думаю, что необходимо посмотреть на отображения linq к sql, использует. На что похожа Ассоциация? Должна быть Ассоциация и на родительских и на дочерних классах. Смотрите на linq к sql Ассоциации между этими двумя классами. Ассоциация должна иметь свойство ThisKey. Состав исполнителей, который перестал работать, пытается бросить значение свойства, на которое указывает ThisKey, я думаю. Насколько я могу сказать, что может быть проблема, когда существует больше чем один ключ, и тип первого ключа не соответствует типу, на который ThisKey указывает также. Я не уверен, как linq определил бы, каков первый ключ. От взглядов его у Вас только есть один ключ и один внешний ключ так, чтобы не должна была быть проблема, но разработчик, если Вы используете его, как было известно, стал творческим. Я в значительной степени предполагаю, но это похоже на что-то, что я видел прежде.
ResponseCode rc = new ResponseCode()
{
SurveyQuestionName = "Q11",
Code = 3,
Description = "Yet another code"
};
и:
INSERT INTO tblResponseCode
(responseCodeTableId, surveyQuestionName, code, description)
VALUES (13683, 'Q11', 3, 'Yet another code')
Не то же, Вы не являетесь передающими в ссылке внешнего ключа. Теперь, я - огромный n00b в LINQ2SQL, но я держал бы пари, что LINQ2SQL не достаточно умен, чтобы сделать это для Вас, и он ожидает это как первый параметр анонимного словаря и пытается бросить строку к целому числу.
Просто некоторые идеи.
Этот блок:
codebookVersion.ResponseCodes.Add(rc);
db.SubmitChanges(); //exception gets thrown here
Можно ли попробовать InsertOnSubmit вместо Add? т.е.
codebookVersion.ResponseCodes.InsertOnSubmit(rc);
Я думаю Add не предназначен, чтобы использоваться для вставки записей если мне не изменяет память. InsertOnSubmit является тем для использования.
Попытаться сузить преступника.
Имейте Вас, пытался заменить анонимный словарь чем-то как:
ResponseCode rc = new ResponseCode();
rc.SurveyQuestName = "Q11";
rc.Code = 3;
rc.Description = "Yet Another Code";
Я должен все же действительно работать с.NET 3.5 все же (дневное задание является все еще всеми 2.0), таким образом, я задаюсь вопросом, существует ли проблема с передачей данных с помощью анонимного словаря (Случаи не соответствуют Столбцам SQL для одного).
Mike, я слышу Вас. Но неважно где я смотрю, все выглядит корректным. Я проверил и перепроверил, что ResponseTableId является интервалом и что идентификатор является интервалом. Они определяются как таковые в разработчике и когда я пошел посмотреть на сгенерированный код, все снова, кажется, в порядке.
Я исследовал ассоциации. Здесь они:
[Table(Name="dbo.tblResponseCode")]
public partial class ResponseCode : ...
...
[Association(Name="CodebookVersion_tblResponseCode", Storage="_CodebookVersion", ThisKey="ResponseCodeTableId", OtherKey="Id", IsForeignKey=true)]
public CodebookVersion CodebookVersion
{
...
}
[Table(Name="dbo.tblResponseCodeTable")]
public partial class CodebookVersion : ...
...
[Association(Name="CodebookVersion_tblResponseCode", Storage="_ResponseCodes", ThisKey="Id", OtherKey="ResponseCodeTableId")]
public EntitySet<ResponseCode> ResponseCodes
{
...
}
И снимок экрана ассоциации в случае, если это поможет:
Дальнейшие мысли?
Да, я считал, что и другие сообщения, но это всегда, кажется, вовлекает кого-то соединяющегося к полю, которое просто имеет уникальное ограничение. Или в случае этого парня (который действительно точно походит на мой), он не получил решение.
Вот родительская таблица:
tblResponseTable definition (which maps to CodebookVersion)
COLUMN_NAME TYPE_NAME
id int identity
versionTag nvarchar
responseVersionTag nvarchar
versionTag действительно имеет уникальное ограничение на него, но это не представлено нигде, что я вижу в материале LINQ-SQL - и так как ничто никогда не переходит к базе данных... все еще застрявшей.
ResponseCode rc = new ResponseCode()
{
CodebookVersion = codebookVersion,
SurveyQuestionName = "Q11",
Code = 3,
Description = "Yet another code"
};
db.ResponseCodes.InsertOnSubmit(rc);
db.SubmitChanges();
Можно хотеть проверить, чтобы видеть, что любые поля в таблицах базы данных, которые установлены сервером дб при вставке новой записи, имеют, который отразился в Linq к схеме SQL. Если Вы выберете поле на Linq к схеме SQL и просмотрите ее свойства, то Вы будете видеть поле, названное "Автоматическое Сгенерированное Значение", которое, если установлено на истинный гарантирует, чтобы все новые записи взяли значение по умолчанию, указанное в базе данных.
LINQ к SQL был удержан от использования, к вашему сведению - http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx.
Я столкнулся с очень похожей проблемой. Я свяжу Вас с моим многословным сообщением: http://forums.asp.net/p/1223080/2763049.aspx
И я также предложу решение, просто предположение...
ResponseDataContext db = new ResponseDataContext(m_ConnectionString);
CodebookVersion codebookVersion = db.CodebookVersions.Single(cv => cv.VersionTag == m_CodebookVersionTag);
ResponseCode rc = new ResponseCode()
{
ResponseCodeTableId = codebookVersion.Id,
SurveyQuestionName = "Q11",
Code = 3,
Description = "Yet another code"
};
db.ResponseCodes.InsertOnSubmit(rc);
db.SubmitChanges();
Где-нибудь в Вашем графе объектов существует ошибка преобразования, базовая модель данных (или модель Linq To SQL) изменилась. Это - обычно что-то как NVARCHAR (1)-> CHAR, когда это должна быть СТРОКА или что-то подобное.
Эта ошибка не является забавой выследить, надо надеяться, Ваша объектная модель является небольшой.
Является ли это примером ошибки ? Если это так, попробуйте запустить свой код в .NET 4.0 сейчас, когда бета-версия вышла.
Если вы, как и я, не готовы начать использовать бета-версию, вы сможете обойти проблему. Проблема, похоже, в том, что LINQ не поддерживает должным образом отношения, определенные в полях, отличных от первичного ключа. Однако термин «первичный ключ» относится не к первичному ключу, определенному в таблице SQL, а к первичному ключу, определенному в конструкторе LINQ.
Если вы перетащили свои таблицы в конструктор, Visual Studio автоматически проверит первичный ключ, определенный в базе данных, и пометит соответствующее поле (поля) класса как «первичные ключи». Однако они не обязательно должны соответствовать друг другу. Вы можете удалить ключ, выбранный Visual Studio, и выберите другое поле (или группу полей). Конечно, вам нужно убедиться, что это логично (у вас должно быть уникальное ограничение в базе данных на поле / поля, которые вы выбираете).
Итак, у меня было 2 таблицы / класса, связанные друг с другом с использованием альтернативного ключа. В родительской таблице было 2 ключа: суррогатный первичный ключ, определенный как int, и альтернативный естественный ключ, определенный как строка. В конструкторе LINQ я определил ассоциацию с помощью альтернативного ключа и столкнулся с InvalidCastException всякий раз, когда пытался обновить это поле ассоциации в дочернем объекте. суррогатный первичный ключ, определенный как int, и альтернативный естественный ключ, определенный как строка. В конструкторе LINQ я определил ассоциацию с помощью альтернативного ключа и столкнулся с InvalidCastException всякий раз, когда пытался обновить это поле ассоциации в дочернем объекте. суррогатный первичный ключ, определенный как int, и альтернативный естественный ключ, определенный как строка. В конструкторе LINQ я определил ассоциацию с помощью альтернативного ключа и столкнулся с InvalidCastException всякий раз, когда пытался обновить это поле ассоциации в дочернем объекте. Чтобы обойти это, я вошел в конструктор LINQ, выбрал int, а затем изменил свойство Primary Key с True на False. Затем я выбрал строку и установил для ее свойства Primary Key значение True. Перекомпилировано, проведено повторное тестирование, и исключение InvalidCastException исчезло.
Глядя на снимок экрана, похоже, что вы можете решить свою проблему, изменив первичный ключ LINQ в ResponseCode с ResponseCode.ID на ResponseCode.ResponseCodeTableID
We had a similar problem, caused by using non-integer keys. Details and hotfix number are here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=351358