microsoft / microsoft/PowerPlatform-DataverseClient-Python

tables.update_column / update_columns: update existing column constraints (retrieve -> PUT + @odata.type) -- no metadata-write path exists today

Abierto
#202 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

enhancement
Lenguaje dominante
Python
Estrellas
60
Forks
23
Merge medio
13 h 53 min
PR fusionados (30 d)
3

Descripción

Summary

client.tables can create, add_columns, and remove_columns, but there is no way to update an existing column's definition -- MaxLength, MinValue/MaxValue, RequiredLevel, DisplayName, Format, etc. Today a caller who needs to widen a text column or change a required level must drop to the raw Web API PUT EntityDefinitions({id})/Attributes({id}) and hand-build the payload, including the derived @odata.type discriminator.

This is also the only place the counter-intuitive PUT-not-PATCH metadata-update contract is exposed to users. Metadata updates go over PUT with merge semantics (partial payloads are honored), which reads like PATCH behavior on the PUT verb. The right fix is not a platform verb change (that is a long pole) -- it is to hide the verb inside the SDK so users never choose it.

Context: parity with the .NET modern client

Microsoft.PowerPlatform.Dataverse.Client.ServiceClient never hits this, because it rides the Organization Service message contracts (Execute(new UpdateAttributeRequest { Attribute = new StringAttributeMetadata { MaxLength = 4000 } })) -- a typed message, no HTTP verb. The Python SDK is Web-API-bound and cannot borrow those contracts, so it should own the retrieve -> modify -> PUT (+ @odata.type) sequence internally to give the same UX (typed fields in, no verb visible).

Proposed change (backward-compatible)

Add update_column (+ update_columns) that accepts the same dict override schema proposed in #194, so create and update share one spec shape:

client.tables.update_column("cfb_CustomerFeedback", "cfb_Comment",
                            {"max_length": 4000, "display_name": "Customer Comment"})

Internally: GET the existing typed attribute -> apply overrides -> PUT back with the correct derived @odata.type. Never expose PUT/PATCH/@odata.type to the caller.

Touchpoints

  • data/_odata.py -- new _update_attribute (retrieve-then-PUT with @odata.type); reuse _odata_base.py::_attribute_payload override-building from #194.
  • operations/tables.py + aio/operations/async_tables.py -- new update_column / update_columns.
  • Unit tests: override application + correct verb / @odata.type on the outbound request.
  • README + CHANGELOG per repo maintenance rules.

Acceptance

  • update_column(..., {"max_length": 4000}) issues a PUT to EntityDefinitions({id})/Attributes({id}) with MaxLength: 4000 and the correct derived @odata.type.
  • Caller never passes a verb or @odata.type.
  • Depends on / shares the override-spec schema from #194.

Related

  • #194 -- create-time column constraints (in progress).
  • microsoft/Dataverse-skills#119 -- documents the raw Web API metadata contract this method replaces.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza con data/_odata.py y _odata_base.py::_attribute_payload; después inspecciona las operaciones de tablas en operations/tables.py y aio/operations/async_tables.py. Verifica la aplicación del override y la solicitud PUT saliente en las pruebas unitarias, incluido el @odata.type derivado; actualiza la README y CHANGELOG según sea necesario. Confirma que la implementación comparte el esquema de override de #194 y mantiene internos el verbo y el discriminator.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
python
Área
api, backend
Tipo de issue
Nueva funcionalidad
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Activo
Claridad
Bien especificado
Aptitud para principiantes
68/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.