New cards

[ricardo8990]

• Agrega un campo al modelo base de to_dict llamado url_reference, con este campo podemos decidir si queremos que un objeto embebido tenga una URL como referencia o el objeto tal cual.
• Corregí algunos tests que no estaban prob ando correctamente los objetos embebidos

Solo falta esperar a que se mezcle cuenca-validations para actualizar requirements.txt y setup.py

[codecov]

Codecov Report

Merging #69 (a4da138) into main (ca227d0) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #69   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines          258       258           
  Branches        42        42           
=========================================
  Hits           258       258           

Flag	Coverage Δ
unittests	100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ca227d0...a4da138. Read the comment docs.

[alexviquez]

Porque no mejor usas un header para definir si se va a consultar el contenido completo o solo se va a consultar el objeto principal, más los url, me refiero a algo como:

headers = {"Content-Attributes":"uris"}
# ó
headers = {"Content-Attributes":"resources"}

eso haría que en otras librerías con el hecho de agregar ese header podamos descargar los objetos anidados.

[alexviquez]

y quitar los prints

[ricardo8990]

Porque no mejor usas un header para definir si se va a consultar el contenido completo o solo se va a consultar el objeto principal, más los url, me refiero a algo como:

headers = {"Content-Attributes":"uris"}
# ó
headers = {"Content-Attributes":"resources"}

eso haría que en otras librerías con el hecho de agregar ese header podamos descargar los objetos anidados.

Creo que si es algo que podríamos agregar, aunque este caso sería el primer paso para llegar a ello. Ya que sería durante los blueprints que de acuerdo al tipo de header se debería de mandar el parámetro o no. En este caso agregué el parámetro ya que los CardActivation de Cuenca siempre deben incluir el objeto embebido, por otro lado, no sé si eso haría que se tengan que estar editando los headers para diferentes peticiones, por ejemplo, alguien usando cuenca-python tendría que hacer algo como:

import cuenca

# Poner headers como resources
cuenca.http.session.headers['Content-Attributes'] = 'resources'
card_activation = CardActivation.create(...)
card = card_activation.card

# Para obtener ahora sus card_transactions, regresar los headers como estaban
cuenca.http.session.headers['Content-Attributes'] = 'uris'
card_activation = CardTransactions.all()

[alexviquez]

Porque no mejor usas un header para definir si se va a consultar el contenido completo o solo se va a consultar el objeto principal, más los url, me refiero a algo como:

headers = {"Content-Attributes":"uris"}
# ó
headers = {"Content-Attributes":"resources"}

eso haría que en otras librerías con el hecho de agregar ese header podamos descargar los objetos anidados.

Creo que si es algo que podríamos agregar, aunque este caso sería el primer paso para llegar a ello. Ya que sería durante los blueprints que de acuerdo al tipo de header se debería de mandar el parámetro o no. En este caso agregué el parámetro ya que los CardActivation de Cuenca siempre deben incluir el objeto embebido, por otro lado, no sé si eso haría que se tengan que estar editando los headers para diferentes peticiones, por ejemplo, alguien usando cuenca-python tendría que hacer algo como:

import cuenca

# Poner headers como resources
cuenca.http.session.headers['Content-Attributes'] = 'resources'
card_activation = CardActivation.create(...)
card = card_activation.card

# Para obtener ahora sus card_transactions, regresar los headers como estaban
cuenca.http.session.headers['Content-Attributes'] = 'uris'
card_activation = CardTransactions.all()

pero podrías hacerlo desde el configure no?, hay recursos que en realidad no harían nada distinto como card_transactions ya que en el to_dict de mongo no tiene campos que tengan referencias, pero del lado del cliente como cuenca-dart o cuenca-node en un futuro sería valioso en un solo request obtener el contexto completo de un balance-entrie o así

[ricardo8990]

Porque no mejor usas un header para definir si se va a consultar el contenido completo o solo se va a consultar el objeto principal, más los url, me refiero a algo como:

headers = {"Content-Attributes":"uris"}
# ó
headers = {"Content-Attributes":"resources"}

eso haría que en otras librerías con el hecho de agregar ese header podamos descargar los objetos anidados.

Creo que si es algo que podríamos agregar, aunque este caso sería el primer paso para llegar a ello. Ya que sería durante los blueprints que de acuerdo al tipo de header se debería de mandar el parámetro o no. En este caso agregué el parámetro ya que los CardActivation de Cuenca siempre deben incluir el objeto embebido, por otro lado, no sé si eso haría que se tengan que estar editando los headers para diferentes peticiones, por ejemplo, alguien usando cuenca-python tendría que hacer algo como:

import cuenca

# Poner headers como resources
cuenca.http.session.headers['Content-Attributes'] = 'resources'
card_activation = CardActivation.create(...)
card = card_activation.card

# Para obtener ahora sus card_transactions, regresar los headers como estaban
cuenca.http.session.headers['Content-Attributes'] = 'uris'
card_activation = CardTransactions.all()

pero podrías hacerlo desde el configure no?, hay recursos que en realidad no harían nada distinto como card_transactions ya que en el to_dict de mongo no tiene campos que tengan referencias, pero del lado del cliente como cuenca-dart o cuenca-node en un futuro sería valioso en un solo request obtener el contexto completo de un balance-entrie o así

Regresé los archivos a cómo estaban, solo dejé la corrección del test que realmente no estaba probando algo en concreto.

[alexviquez]

ajustar las librerías y crear un issue para explorar el tema que platiccamos de los headers a futuro, incluso se me ocurre que podríamos no manejarlo del header, si no manejarlo desde la url tal y como jsonapi lo hace, es decir en el get añadir un attributes=related_transaction, funding_instrument y si no trae como atributo el campo, no hacer el fetch y dejar solo la url del recurso, en caso contrario crear el objeto anidado

[ricardo8990]

ajustar las librerías y crear un issue para explorar el tema que platiccamos de los headers a futuro, incluso se me ocurre que podríamos no manejarlo del header, si no manejarlo desde la url tal y como jsonapi lo hace, es decir en el get añadir un attributes=related_transaction, funding_instrument y si no trae como atributo el campo, no hacer el fetch y dejar solo la url del recurso, en caso contrario crear el objeto anidado

Issue #72 y librerías actualizadas

[alexviquez]

fierro