Сущности в системе идентифицируются Guid. который, будучи преобразованным в строку, имеет вид типа "846d8d33-004b-4a3e-b778-10cfd163f3bb" (буквы строчные, в таком виде он фигурирует, например, в параметрах запросов http)
С другой стороны в БД сущности хранятся с первичным ключем, построенным на id varchar2(38), но содержиное там заключено в фигурные скобки и буквы заглавные.
Есть ли стандартная функция преобразования одного в другое? В запрос нужно передать Id текущего контакта, но "{"+UserConnection.CurrentUser.ContactId.ToUpper()+"}" выглядит достаточно неуклюже.
Нравится
Могу предложить "элегантный костыль":
string contact = "846d8d33-004b-4a3e-b778-10cfd163f3bb";
string result = String.Join(String.Empty, "{", contact.ToUpper(), "}");
Если используете механизмы EntityShchemaQuery или Select/Insert/Update/Delete, то ничего преобразовывать не нужно, в функции передаётся переменная типа Guid и при генерации SQL в нужном формате подставится само. Если же самостоятельно создаёте SQL, воспользуйтесь своим кодом или советом выше.
Эелегантность костыля в виде сокращения записи обращения к переменной иррелевантна задаче :)
Меня больше интересовал источник подобных сложностей, почему сразу было не привести к одному формату? Ведь была ж какая-то причина?
Причина в том, что основная поддерживаемая база — MS SQL, где есть тип «uniqueidentifier» и база поймёт вставку в любом формате. А поддержка Oracle добавлена опционально.
В этом и была суть вопроса: если в Oracle используется просто текст, какая разница, что туда писать? Зачем эти скобочки? Чтобы что-то в базе посмотреть, скопировать Id из URL не получится, это минус. Как и при склеивании ESQ и Select. А плюсы вообще есть?
Этот текст, хоть и не является отдельным типом «uniqueidentifier», но служит в качестве первичного или внешнего ключа. Соответственно, если писать в двух полях один GUID разным способом, связи между ними не получится.
Зверев Александр,
В каких 2-х полях??? Почему не писать ОДНИМ способом, в нижнем регистре и без скобок? Везде.
В версии для MS SQL пишите как вам нужно, а в Oracle — именно требуемым способом.
Зверев Александр,
Спасибо, я ожидал компетентный ответ, а не бессмысленный совет следовать инструкциям, я им и так следую, но не могу понять необходимость такого усложнения и препятствия к его устранению. Если препятствий нет, то, думаю, все, кто на Oracle, меня поддержат, было бы хорошо привести все к единому знаменателю.
Дмитрий, оно и приведено к единому знаменателю — с фигурными скобками в верхнем регистре. Нет смысла в версиях с 3.0 по 7.13 использовать один формат, а потом внезапно менять просто потому, что не нравятся скобки.
Я написал, что не нравится: дело не в скобках, а в отсутствии целостности восприятия. Я понял, что это чье-то давнишнее головотяпство, последствия которого сейчас уже сложно ликвидировать, а негативное влияние считается минимальным. При этом корпоративная этика не позволяет это признать на людях. В принципе, лучше было вообще не реагировать на мой вопрос, но в любом случае спасибо.
При обычной работе с форматом написания не сталкиваются никак, все C#-классы принимают значения типа Guid и преобразуют в нужный формат при генерации SQL автоматически. В чём именно негативное влияние фигурных скобок, Вы так и не объяснили.
Вероятно, первоисточник именно такого написания — стандартная функция CreateGuid в Delphi, на котором была написана система Terrasoft 3.X. Она генерирует именно в таком формате. И в таблицу базы Firebird и Oracle, где нет встроенных типов для хранения GUID, так и записывали.
В Microsoft для C# рекомендуют для получения нужного формата использовать для переменной типа Guid метод ToString("N") в сочетании с String.ToUpper.