Tubos siguen casi inservibles, crear nueva idea?

Hola a todos.
Ya existe una idea sobre los tubos v7, para resolver algo BASICO en cualquier herramienta de desarrollo, que es COPIAR REGISTROS de una tabla a otra.
https://velneo.zendesk.com/entries/21890268-Automatizar-resolucion-de-TUBOS-

Este 2015, salieron los tubos json, que siguen siendo morosos, distan de ser una automatizacion tipo TablaDestino.registro()=TablaOrigen.Registro().

Pero mas que todo, acabo de confirmar con soporte que, ni se pueden usar en un proyecto de datos (es decir, olvidarse de usarlo en un trigger), ni se pueden usar en tercer plano

Justamente la potencia de copiar registros, es poderlo hacer en EN EL LADO DEL SERVIDOR, pues los escenarios de uso masivo, deben hacerse así y no estar congestionando innecesariamente el trafico de red.

En general, pregunto, ¿como Velneo entonces se ufana tanto de estar orientado a trabajar en la nube? cuando:

1.- Para una busqueda de muchos componentes, hay que usar tropecientos SET y GET, para tener optimizada esa busqueda para trabajar en la nube https://velneo.zendesk.com/entries/23758281-Carga-de-listas-proceso-optimizado-para-la-nube-POR-DEFAULT-
2.- Un informe, no puede funcionar en 3er plano. https://velneo.zendesk.com/entries/23650928-Informes-externos-en-3-plano Obligando a morosos workarounds, en vez de funcionar nativamente en el lado servidor.
3.-Los tubos JSON no funcionan en tercer plano, lo que acabo de plantear.

Sobre esto de los tubos, conviene una idea nueva? o insistir sobre la existente (que los tubos sean NATIVOS y que puedan usarse desde un proyecto de datos )?

Opiniones en general? No es esto de estar optimizado para la nube, mucho mas urgente que otras ideas ya trabajadas?

Gracias de antemano por cualquier opinión.
Saludos

Opino igual la verdad, el tema de copiar registros entre tablas se hace infumable en 3er plano, teniendo que recurrir a cientos de set y cientos de modificar campo ya que los tubos no son usables.

+1

igualmente +1

Buen día,

Aparte de lo ya mencionado, ¿que problemas puntuales hay con los tubos?, yo el único que he encontrado es el de que si modificas la estructura de la tabla insertando un campo en un punto que no es el último, no se “refactoriza” el tubo, vamos, a partir de ahí hay que ir volviendo a “re-apuntar” la resolución del campo.

Y, todavía me queda la duda, en algunas ocasiones tengo problemas con el traspaso de campos tipo fecha o tiempo, pero no me queda claro si es error mio o del tubo.

En general los utilizo bastante para sincronizar oficinas foráneas que no cuentan con internet contra un servidor central y me parece en general bueno el funcionamiento, muy rápido con algunos miles de registros diarios.

Por eso me gustaría saber exactamente qué otros problemas hay.

Saludos.

@aztecmexico Cuando dices “Aparte de lo ya mencionado,”, yo me pregunto ¿te parece poco lo ya mencionado? En los tubos nativos, hay que definir los campos UNO POR UNO, casi lo mismo que estar definiendo variables locales. Con la dificultad adicional de que si modificas la estructura de tablas, a perder mas tiempo porque el tubo se despatarra.

¿Como se comparan esa forma de trabajar con un deep assignment del estilo TablaDestino.Registro()=TablaOrigen.Registro() ?

¿Para que sirven herramientas como estos tubos, que prácticamente no te ahorran nada de tiempo, comparado con hacerlo ‘a lo tonto’?

Y si tienes conceptos sólidos de bases de datos, y sobre lo que significa trabajar EN LA NUBE, pues estará muy fácil que entiendas lo que significa de que los tubos no puedan usarse en tercer plano, ni en triggers.

Hola Cesar,

Simplemente pensaba que había otros comportamientos raros o fallas adicionales, y si, me parece poco, pero de momento, porque no he tenido necesidad de usar tan a fondo los tubos, será que le dedico demasiado tiempo a planear y diseñar mis bases de datos y estructuras y por eso despues mi necesidad de utilizarlos es mínima, pero igual el día que tenga que llegar a ese nivel de uso me quejaré con ganas.

No sé como se compara esa forma de trabajar porque hace mucho dejé de usar y trabajar con otras bases de datos porque me harté de tanta paja para hacer cosas que deberían ser sencillas y desde mi muy particular punto de vista los grandes fabricantes de las mismas las diseñan de tal forma que tengas que estudiar, prepararte, certificarte, etc, etc, etc, para hacer cosas que, repito, desde mi muy particular punto de vista se deberían hacer solas o ni siquiera se deberían hacer.

¿Para que sirven esos tubos?, pues a mi me han servido mucho, conociendo las limitaciones que ya mencione y que tú tambien mencionas, y me vas a disculpar, pero si ahorran mucho tiempo, en lo particular procuro no programar ni diseñar a lo tonto, precisamente para evitarme o darle la vuelta a ese tipo de problemas. No los uso mucho, de hecho, en la medida de lo posible procuro no utilizarlos, y no me molesta, bueno, a veces si, reajustarlos cuando agrego campos a tablas, ni modo, uno por uno, pero, pues eso tambien se cobra, aunque sea una limitante de la base de datos, ¿o qué me vas a decir que oracle o sql server o cualquier empresa de consultoría no cobran por arreglar o ajustar programación aún cuando la falla obedezca a errores de las mismas bases de datos?, pues si, cobran y mucho. Todo es negocio.

No se si tenga conocimientos sólidos de Bases de Datos, creo que 30 años desarrollando no me dan todavía la suficiente experiencia, vamos, yo que todo lo hacia en COBOL y con transmision de datos a 1200 baudios por segundo para enviar una nómina de 1200 empleados de Guadalajara al DF, lo de la nube, pues creo que antes le deciamos por otro nombre, pero como NUBE está de moda y yo me quedé con el concepto original pues entonces creo que no sé que sea eso, y eso que mis clientes tienen oficinas en varios lugares y sus oficinas se conectan a la aplicación central.

Lo del tercer plano y triggers, totalmente de acuerdo, aunque no se si realmente lo llegue a entender, pero haré el esfuerzo.

Saludos.

“Lo del tercer plano y triggers, totalmente de acuerdo, aunque no se si realmente lo llegue a entender, pero haré el esfuerzo.”
Si tienes tanta experiencia (yo tengo algo menos de años, pero si muchísima diversidad de bases de datos y herramientas, siempre optimizando para minimizar el trafico de red), deberias tener muy claro que son los triggers (y stored procedures en otras bases), salvo que le llamen otra cosa en tu país.

Lo que llaman tercer plano en Velneo SA, es simplemente procesamiento DEL LADO DEL SERVIDOR. Creí haberlo explicado claramente en mis 3 puntos de mi primer mensaje.

Y el punto es que si Velneo sacrifica la posibilidad de trabajar sobre otras bases de datos (que es una limitacion demasiado grande, que obliga a trabajar solo con un cierto subset de tus clientes), fue con el argumento de que lo hacia porque el IDE estaba mucho mas integrado a la base, para lograr el desarrollo ‘life is soft’. Pero si en cosas ULTRA-BASICAS te obliga a trabajar mas que con otras herramientas (los tubos que te obligan a definir campo por campo en vez de un deep asignment, y que ni las nuevas versiones te permiten trabajar en triggers ni en tercer plano, o las busquedas que no son server-side por default), donde esta la mayor integración entre el IDE y la base de datos?

Creo #cjribera que aun está en el foro de ideas con 27 puntos el hilo que iniciaste tú a este respecto

https://velneo.zendesk.com/entries/21890268-Automatizar-resolución-de-TUBOS-

en el que yo propuse una serie de ideas con respecto a este tema de los tubos

No estaría de más que insistiéramos en ello, que es una idea, que está votada 27 veces y que debería estar planeada ya.
Otras, también interesantes sin duda, las planearon ya y con menos puntos

Yo, personalmente, cuando hablo con alguno de los responsables del proyecto les hago ver este punto con bastante insistencia
y me temo que me van a poner el apodo de “el tubero”

Insistan todos, por favor