Действительно ли COM мертв? [закрытый]
Пример использования клиентской библиотеки Python. Адаптировано из здесь , но добавляется вызов get_dataset для получения текущей политики ACL для уже существующих наборов данных:
from google.cloud import bigquery
project_id = "PROJECT_ID"
dataset_id = "DATASET_NAME"
group_name= "google-group-name@google.com"
role = "READER"
client = bigquery.Client(project=project_id)
dataset_info = client.get_dataset(client.dataset(dataset_id))
access_entries = dataset_info.access_entries
access_entries.append(
bigquery.AccessEntry(role, "groupByEmail", group_name)
)
dataset_info.access_entries = access_entries
dataset_info = client.update_dataset(
dataset_info, ['access_entries'])
Другой способ сделать это - использовать Клиент Google Python API и методы get и patch . Сначала мы извлекаем существующий ACL набора данных, добавляем группу как READER к ответу и исправляем метаданные набора данных:
from oauth2client.client import GoogleCredentials
from googleapiclient import discovery
project_id="PROJECT_ID"
dataset_id="DATASET_NAME"
group_name="google-group-name@google.com"
role="READER"
credentials = GoogleCredentials.get_application_default()
bq = discovery.build("bigquery", "v2", credentials=credentials)
response = bq.datasets().get(projectId=project_id, datasetId=dataset_id).execute()
response['access'].append({u'role': u'{}'.format(role), u'groupByEmail': u'{}'.format(group_name)})
bq.datasets().patch(projectId=project_id, datasetId=dataset_id, body=response).execute()
Заменим project_id, dataset_id, group_name и [118 ] переменные соответственно.
Используемые версии:
$ pip freeze | grep -E 'bigquery|api-python'
google-api-python-client==1.7.7
google-cloud-bigquery==1.8.1
5 ответов
Нет это еще не мертво, но это находится на своем смертном ложе, это наверняка. Вы видите, что существует все еще ко многим унаследованным системам, которые используют/требуют COM, который уверяет нас, что это будет с нами в течение еще нескольких лет, но не в конечном счете.
Что касается WCF, могли бы быть некоторые пограничные случаи материала, который может сделать COM, и WCF не может, но что еще более важно, и связанный с материалом прежней версии, быть, что существует привязка COM почти для каждого языка, можно поставить стопку окон, но привязка WCF еще не готова ко всем (языки)
Зависит от того, как глубоко в систему Вы хотите вырыть. COM никогда не будет 'умирать', то же, поскольку неуправляемые языки никогда не будут.
Для создания, короче говоря, при разработке настольных приложений для Vista + Вы, вероятно, не должны будете потрудиться использовать COM больше.
Я не думаю, что COM мертв. При рассмотрении Vista она использует большую часть архитектуры/технологии COM. Каждой вещью в Vista является COM Dll/Exe. Я чувствую по сравнению с XP, Vista использует большую часть COM.
Если мы хотим расширить какую-либо вещь в Vista, мы должны реализовать интерфейсы с помощью COM.
Если я не ошибаюсь.NET предназначается для замены технологии как COM и WFC. Существует ли причина (кроме унаследованного кода), что каждый был бы, выбрал COM или WFC over.NET?
Существует несколько различных аспектов:
- Компоненты, которые будут работать и взаимодействовать с несколькими компьютерами (как службы)
- Компоненты, которые работают только локально и взаимодействуют с компонентами, реализованными несколькими поставщиками через ABI.
- Компоненты, созданные одним поставщиком, без необходимости взаимодействия со сторонними компонентами.
- Компоненты от нескольких поставщиков, доступные в исходном коде, которые можно скомпилировать в одно приложение.
(ABI = двоичный интерфейс приложения. COM является примером ABI.)
Для аспекта 1 COM практически мертв.
Аспект 2 по-прежнему требует COM, и так и будет. Компонент Windows Imaging - отличный пример такой расширяемости, позволяющий любому внедрять новые кодеки изображений. .Net - сильный соперник в этом аспекте.
Что касается аспекта 3, COM все еще стоит рассмотреть, но это решение должно приниматься каждым поставщиком программного обеспечения. Разработчик компонентов для внутреннего использования может однажды быть продан как продукт. .Net здесь тоже кажется хорошим выбором.
Для аспекта 4 можно просто адаптировать и комбинировать исходные коды многих проектов с открытым исходным кодом. Нет необходимости ни в COM, ни в каком-либо ABI.
COM как неуправляемый ABI, к сожалению, сложно защитить от ошибок, потому что код и данные находятся в одном пространстве памяти, а стек используется как для данных, так и для стека вызовов выполнения. Любая уязвимая дыра в одном COM-компоненте может быть использована, чтобы вызвать нестабильность в любых других COM-компонентах, загруженных в то же адресное пространство.