Replicación en GemStone
GallegO
No puedo creer que no exista una forma de replicar un repositorio en
forma automática. ¿Es realmente así?
En la documentación no vemos nada que indique que podemos replicar o
distribuir repositorios.
Tampoco veo info sobre como exportar objetos de un repositorio y
montarlos en otro, si bien esto se puede resolver con serialización no
encontré que haya soporte de base.
Me gustaría saber cómo resuelven estos problemas, si existen claro está.
Saludos y Gracias!
GallegO
Andres Valloud
2008/12/2 GallegO <fxga...@gmail.com>:
>
> Para los GemStone users:
>
> No puedo creer que no exista una forma de replicar un repositorio en
> forma automática. ¿Es realmente así?
De lo poco que se, lo que me viene a la mente es pasar los transaction
logs a otro lado donde haya un mirror del repositorio y ejecutarlos en
el mirror en forma paralela con la base de produccion.
Andres.
Nahuel Silva
Ah, sino lista de gemstone te responde jemes foster al toque :)
Salutti
Hernan Wilkinson
Para los GemStone users:
No puedo creer que no exista una forma de replicar un repositorio en
forma automática. ¿Es realmente así?
En la documentación no vemos nada que indique que podemos replicar o
distribuir repositorios.
Tampoco veo info sobre como exportar objetos de un repositorio y
montarlos en otro, si bien esto se puede resolver con serialización no
encontré que haya soporte de base.
GallegO
Gracias por las respuestas. En realidad lo que me esperaba era una
replicación automática, como tiene Oracle o SQL Server. Entiendo que no
es el caso más común pero en algunos clientes es necesario por problemas
de conectividad. Incluso a veces de muy difícil solución sino imposibles.
Creo que lo que más se acerca es lo que me comentaba Andres de los
transactions logs. El tema es que eso funcione para más de un
repositorio y no solo entre pares. En todo caso le preguntaré a James.
Que me pueden comentar acerca de la performance Smalltalk de GemStone?
Se puede comparar con VW, VAST, Dolphin?
Supongo que esto que pregunto aplica más a su uso como plataforma GLASS
y no como simple base de datos de objetos.
Algún ratio con respecto a un Smalltalk común?
Gracias por sus respuestas!!
Saludos
GallegO
Nahuel Silva escribió:
> a lo cabeza, funciona de diez :D eso si fijate que no esté levantado
> el repositorio sino explota.
>
> Ah, sino lista de gemstone te responde jemes foster al toque :)
>
> Salutti
>
> On Tue, Dec 2, 2008 at 6:00 PM, Andres Valloud
> <andres....@gmail.com <mailto:andres....@gmail.com>> wrote:
>
>
> Buenas...
>
Nahuel Silva
Podés hacer todos esos procesos automatizados en un .sh si estas en linux sino en un .bat, a través de topaz, y sale como trompada, la verdad que no se me ocurre mucho más.
Respecto al tema de prformance no puedo comentarte mucho porque la verdad todavía no estuve tocando mucho desde smalltalk.
Lo que puedo asegurar es que gemstone es muy groso, siempre y cuando no te olvides de correr markForCollection habitualmente ;)
Salutti
GallegO
Gracias por responder. Te contesto entre lineas:
Hernan Wilkinson escribió:
> No se a que te referís exactamente con replicar un repositorio en
> forma automática, pero te comento las opciones:
>
Si me refiero a la terminología de las RDBMS tradicionales. Por ejemplo,
tenemos una base de datos en Cuba y otra en Canadá. En el esquema que
tenemos con SQL Server ambas bases de datos se mantienen sincronizadas.
Se puede configurar esa sincronización para cada tabla. Lo que me
pregunto es cómo podría tener dos repositorios de GemStone sincronizados
de esa manera. Por lo que me cuentan parece que no se puede en forma
automática y on-line.
>
>
> En la documentación no vemos nada que indique que podemos replicar o
> distribuir repositorios.
>
>
> Si se puede. Replicar te lo comenté arriba, opción 1.
> A que te referís con distribuir? poner los archivos en distintos
> servidores? también podes, simplemente configurá las
> opciones DBF_EXTENT_NAMES y STN_TRAN_LOG_DIRECTORIES y listo.
> ¿Qué documentación estás leyendo? Fijate de estar leyendo la System
> Administration Guide, no la Programming Guide
>
Si la de administración (pero tengo que reconocer que la leí por encima
sin detenerme en los detalles). Es interesante que se puedan por lo
menos mantener los archivos en otros servidores. Con respecto a la
distribución es también referido a la tecnología tradicional y
relacionado con la sincronización. Volviendo al caso anterior podría
tener objetos en distintas bases y yo decidir cuales viajan de un
repositorio a otro. En este caso es más difícil entender como sería esto
ya que a nivel de rows lo veo más fácil, aunque en Gemstone los objetos
también tienen un OID...
> Lo que se hace generalmente para esto es un file out y file in. El
> file out funciona a nivel objeto no solo clase.
No sabia.
> Lo que pasa que si es mucho lo que tenes que exportar... que se yo...
> Lo otro que podes hacer es muy simple, desde un Smalltalk te conectas
> al stone source y target al mismo tiempo y vas copiando de uno a otro.
> No es tan sencillo porque tenes que hacer copias de los que vas
> leyendo del source porque el GemKit no te deja que el mismo objeto
> pertenezca a dos sesiones distintas (y con razon, sino se producirían
> conflictos transaccionales), pero bue, es una opción.
>
Si, lo que pasa que me estaba inclinando para el lado de GLASS, por eso
las opciones que incluyen conectarme con VW o VAST no las tengo en cuenta.
Uds. no tienen problemas de ese tipo con bases de datos que estan muy
lejanas entre si? Siempre confían en la conexión o siempre trabajan en
una LAN?
Saludos
GallegO
Hernan Wilkinson
Andres, Nahuel:
Gracias por las respuestas. En realidad lo que me esperaba era una
replicación automática, como tiene Oracle o SQL Server. Entiendo que no
es el caso más común pero en algunos clientes es necesario por problemas
de conectividad. Incluso a veces de muy difícil solución sino imposibles.
Creo que lo que más se acerca es lo que me comentaba Andres de los
transactions logs. El tema es que eso funcione para más de un
repositorio y no solo entre pares. En todo caso le preguntaré a James.
Que me pueden comentar acerca de la performance Smalltalk de GemStone?
Se puede comparar con VW, VAST, Dolphin?
Supongo que esto que pregunto aplica más a su uso como plataforma GLASS
y no como simple base de datos de objetos.
Algún ratio con respecto a un Smalltalk común?
Hernan Wilkinson
Hernan:
Gracias por responder. Te contesto entre lineas:
Hernan Wilkinson escribió:
> No se a que te referís exactamente con replicar un repositorio enSi me refiero a la terminología de las RDBMS tradicionales. Por ejemplo,
> forma automática, pero te comento las opciones:
>
tenemos una base de datos en Cuba y otra en Canadá. En el esquema que
tenemos con SQL Server ambas bases de datos se mantienen sincronizadas.
Se puede configurar esa sincronización para cada tabla. Lo que me
pregunto es cómo podría tener dos repositorios de GemStone sincronizados
de esa manera. Por lo que me cuentan parece que no se puede en forma
automática y on-line.
>Si la de administración (pero tengo que reconocer que la leí por encima
>
> En la documentación no vemos nada que indique que podemos replicar o
> distribuir repositorios.
>
>
> Si se puede. Replicar te lo comenté arriba, opción 1.
> A que te referís con distribuir? poner los archivos en distintos
> servidores? también podes, simplemente configurá las
> opciones DBF_EXTENT_NAMES y STN_TRAN_LOG_DIRECTORIES y listo.
> ¿Qué documentación estás leyendo? Fijate de estar leyendo la System
> Administration Guide, no la Programming Guide
>
sin detenerme en los detalles). Es interesante que se puedan por lo
menos mantener los archivos en otros servidores. Con respecto a la
distribución es también referido a la tecnología tradicional y
relacionado con la sincronización. Volviendo al caso anterior podría
tener objetos en distintas bases y yo decidir cuales viajan de un
repositorio a otro. En este caso es más difícil entender como sería esto
ya que a nivel de rows lo veo más fácil, aunque en Gemstone los objetos
también tienen un OID...
> Lo que se hace generalmente para esto es un file out y file in. ElNo sabia.
> file out funciona a nivel objeto no solo clase.
> Lo que pasa que si es mucho lo que tenes que exportar... que se yo...Si, lo que pasa que me estaba inclinando para el lado de GLASS, por eso
> Lo otro que podes hacer es muy simple, desde un Smalltalk te conectas
> al stone source y target al mismo tiempo y vas copiando de uno a otro.
> No es tan sencillo porque tenes que hacer copias de los que vas
> leyendo del source porque el GemKit no te deja que el mismo objeto
> pertenezca a dos sesiones distintas (y con razon, sino se producirían
> conflictos transaccionales), pero bue, es una opción.
>
las opciones que incluyen conectarme con VW o VAST no las tengo en cuenta.
Uds. no tienen problemas de ese tipo con bases de datos que estan muy
lejanas entre si? Siempre confían en la conexión o siempre trabajan en
una LAN?
Saludos
GallegO
GallegO
> mmm pero porque motivo querrías tener varios repositorios? Cual sería
> la ventaja.
> Creo que en Kapital tinen varios repositorios... Lucho estás ahí?
> podes comentar algo al respecto?
> El OID de los objetos en GemStone está oculto... no está para ser
> usado lo cual me parece correcto
a ningún vendedor le gusta jaja (vos no sos vendedor no? jeje)
Bueno la ventaja es ninguna. Yo seria feliz sino tuviéramos que tenerlo,
el caso es que algunas conexiones son muy poco fiables, o tienen cortes
(no micro) o son satelitales 128 - 256 hasta 512 no se si algo más. Y el
sistema tiene que funcionar en todas las locaciones, por lo general 24*7
en las empresas más exigentes (y trabajadoras).
>
>
> Nuestras aplicaciones están siempre en LAN. La de Kapital está en WAN
> o más... en New York se conectan a Londres... por eso hicieron unos
> cambios a partir de la versión 6.3 donde pusieron una cache intermedia
> adicional entre los Gem y el share page chace del Stone... No se que
> tipo de conexión tienen entre New York y Londres, pero funca... seguro
> es buena.
Claro, me imagino que las conexiones del primer mundo son buenas. Ademas
los bancos, me imagino, están muy aceitados en eso.
En Argentina es bastante difícil tener conexiones de buena calidad y
baratas en algunos puntos del país (en medio del campo). Eso hace que
las empresas más chicas se vena un poco limitadas a la hora de tener
varias conexiones por redundancia. Incluso las empresas más grandes a
veces tienen problemas.
Saludos
GallegO
GallegO
> La performance de GemStone es menor comparada con cualquier Smalltalk
> común por un hecho muy simple, tiene que poder escalar a disco todo lo
> que tiene en memoria, esto implica que a veces manda a disco zonas de
> memoria que estás usando o a veces tiene que traer de disco zonas de
> memoria que necesitas. Además, hay que tener en cuenta todo el trabajo
> necesario que tiene que hacer para poder determinar cuando se hace
> commit que objetos debe modificar, etc.
también es lenta. En algún lado tenemos que guardar... save image
abstenerse de hacer comentarios :D
> Un tema importante a tener en cuenta en la performance también es el
> tiempo que consume el GemKit. El GemKit es el componente de GemStone
> que instalas en VW o VAST para ver a GemStone como otro Smalltalk, o
> sea, es el responsable de hacerte creer que estás trabajando con
> objetos en tu Smalltalk en vez de con GemStone. Entonces, no es lo
> mismo probar performance desde VW o directamente en un Gem (la VM de
> GemStone), se entiende? O sea, el trabajo que tiene que hacer el
> GemKit de replicación de objetos o forwarding de mensajes impacta.
> Ojo, con esto no quiero decir que la performance es mala, sino que hay
> que tener en cuenta estas cosas.
perfomance de GemStone.
> Así y todo, la VM de GemStone (el Gem) es más lento que el resto. Por
> ejemplo, correr esto:
> Time millisecondsToRun: [ 10000 timesRepeat: [ | coll | coll :=
> OrderedCollection new. 10000 timesRepeat: [ coll add: 1 ]]]
> En VAST lleva: 3453
> En VW lleva: 5712 (Sorpresivamente casi el doble...)
> GemStone 6.1.4, o sea, 32 bits)
Si, en el curso de GemStone de Smalltalks 2008 calculamos un factorial
grande y tardo mucho, mucho, ya con eso nos imaginamos que la
performance como Smalltalk era menor.
También vimos como Squeak calculaba factorial más rápido que VW (Todavia
no lo puedo creer y aún tengo dudas sobre eso ja!)
Lo que si hay que reconocer que en GemStone, comparado con una
relacional no tenes el costo de instanciación como en las relacionales,
siempre hablando de no usar GemBuilder y usar GLASS, claro esta.
>
> Si querés datos de performance de GLASS, andá la blog del tipo que lo
> está haciendo que tiene varios datos sobre hits per second, etc.
>
Si, es bastante buena, eso es gran punto a favor de GLASS.
Saludos
GallegO
Gerardo Richarte
asi que no puedo aportar mucho.
Pero mirá este post de Dale Henrichs sobre algunas medidas rapidas que
hizo de performance de aplicaciones hechas en GLASS.
http://gemstonesoup.wordpress.com/2007/10/19/scaling-seaside-with-gemstones/
es muy interesante. Cuantos requests necesitas poder contestar por segundo?
me gustaria saber esa respuesta. En la prueba que peor le fue aguanta 10
por segundo.
Fijate las respuestas al post, la primera de Avi Bryant (el que
originalmente hizo Seaside y ahora tiene dabbledb.com un site que
recomiendo mucho navegar, hecho en Seaside... y Squeak por detras, con
persistencia unicamente en ImageSegments).
Obviamente, una opcion recomendable siempre es usar fastcgi (diria que
si vas a armar un webserver de cero uses lighttpd y no apache, lighttpd
es mucho mas chiquito y rapido, pero no tiene todas las cosas de
apache... que no vas a necesitar si usas Seaside), y pongas todo el
contenido estatico (imagenes, quizas javascripts, QUIZAS css, flash,
video, etc) directamente afuera del seaside.
Siempre depende de los requerimientos de tu aplicacion, obviamente.
richie
Esteban A. Maringolo
existe la posibilidad de tener una distribución física de las bases de
objetos tolerante a pérdidas de conexión.
En sistemas "antiguos" (RDBMS), esto se puede lograr mediante el uso
de réplica de datos, ya sea mediante triggers o mediante el log de
transacciones, ya que al perder conexión la base A con la B, los que
estan conectados a la A pueden seguir trabajando localmente sin
enterarse que la BD perdió conectividad. Una vez restaurada la
conexión, el sistema de réplica actualizará lo que tenga que
actualizar, que fue quedando encolado (queued) en el servidor
correspondiente.
En el System Administration Guide de GemStone, menciona la posibilidad
de replicar los transaction logs, pero eso no se si se puede hacer de
manera bidireccional. Además tampoco aclara como se podría hacer, dado
que en una base de datos relacional la estructura a replicar es
siempre la misma, se replican cambios a nivel de filas en una o más
tablas, en cambio en un ODBMS la "estructura" es arbitraria.
No se trata solo de tener más servidores para hacer escalar en cuanto
a desempeño y rendimiento, sino en tener más servidores para que
puedan atender de manera distribuida y tolerante a fallos de
comunicación.
Saludos.
Esteban A. Maringolo
Juan Buligovich
Hernán comentaba
me
acuerdo el nombre... pero básicamente lo que hace es anotarse como
observer
de los cambios realizados en un repositorio y replicarlos en otro...
nunca
la use pero se que existe. Te conviene preguntar en la lista de
gemstone por
ella."
En el capítulo 1, última sección (1,7) del manual SysAdminGuide para
GemStone 6.1 (estamos utilizando GemStone 6.1.2 y 6.1.5) explica cómo
operar con un duplicate server. Se basa en un segundo GemStone Server
corriendo permanentemente a modo restore. El segundo server se
alimenta de la información en los logs generados por el server
principal.
Creo que esta opción es piola como para poder conmutar rápidamente al
segundo server si se cae el primero. Para eso habría que hacer un
commitRestore para sacar al segundo server de la modalidad restore.
Gallego, por lo que entendí de tus comentarios esto no te serviría. O
mejor dicho, te serviría si fueran dos servers activos, o que el
segundo server funcionara como nodo más cercano y que la maquinaria
GemStone terminaran sincronizándolos transparentemente.
Me parece que GemStone -al menos en las versiones que conozco- no
tiene algo así.
Saludos
Juan
GallegO
> yo tambien estoy haciendo cosas con GLASS, empezando, y nada serio,
> asi que no puedo aportar mucho.
>
> Pero mirá este post de Dale Henrichs sobre algunas medidas rapidas que
> hizo de performance de aplicaciones hechas en GLASS.
>
> http://gemstonesoup.wordpress.com/2007/10/19/scaling-seaside-with-gemstones/
>
> es muy interesante. Cuantos requests necesitas poder contestar por segundo?
> me gustaria saber esa respuesta. En la prueba que peor le fue aguanta 10
> por segundo.
>
>
creo que tantos por segundo.
La perfomance me preocupa más por el lado de procesamiento de
información, cálculos, consultas de cientos de miles de instancias,
agruparlas para sumarizar, etc.
Ese es un tipo de uso, podemos denominarlo de consulta y requiere un
esfuerzo considerable cuando consultamos muchos datos.
El otro tipo de uso seria el de ingreso de datos, que requiere mucha
menos capacidad de procesamiento y tampoco se trata de que tenemos miles
de usuarios accediendo.
Por esto que explico, por ahora, no me preocupa tanto los hits por
segundo como si me preocupa la capacidad de procesamiento.
> Fijate las respuestas al post, la primera de Avi Bryant (el que
> originalmente hizo Seaside y ahora tiene dabbledb.com un site que
> recomiendo mucho navegar, hecho en Seaside... y Squeak por detras, con
> persistencia unicamente en ImageSegments).
>
>
Si lo he visto en varias oportunidades.
> Obviamente, una opcion recomendable siempre es usar fastcgi (diria que
> si vas a armar un webserver de cero uses lighttpd y no apache, lighttpd
> es mucho mas chiquito y rapido, pero no tiene todas las cosas de
> apache... que no vas a necesitar si usas Seaside), y pongas todo el
> contenido estatico (imagenes, quizas javascripts, QUIZAS css, flash,
> video, etc) directamente afuera del seaside.
>
>
Si, teníamos pensado hacerlo así. El tema es que por ahora lo estamos
haciendo todo con Dolphin y BD relacionales. Te imaginas, escalar con
Dolphin es image based, aunque tenemos alguna esperanza en que esto
cambie un poco con DNG, o si pasamos a GLASS.
Otro problema es la comunicacion de GLASS con el mundo exterior, he
leido que quieren implementar FFI quizas eso ayude bastante. Por ahora
todo files y sockets. Un poco duro. Pregunte por el precio del
GemConnect y cri cri
Saludos
GallegO
Gerardo Richarte
> Lo que el Gallego pregunta, que ya conversamos personalmente, es si
> existe la posibilidad de tener una distribución física de las bases de
> objetos tolerante a pérdidas de conexión.
>
despues particularmente de la de GLASS. Ese post del blog de Dale es muy
bueno, y se entiende claramente para que cosas te alcanza y para que
cosas no GLASS (en este sentido), y tambien se adivina como escala
(extrapolando de las muchas pruebas que estan documentadas)
richie
GallegO
Como explicas vos, no serviría.
Saludos
GallegO
Juan Buligovich escribió:
Hernan Wilkinson
Otro problema es la comunicacion de GLASS con el mundo exterior, he
leido que quieren implementar FFI quizas eso ayude bastante. Por ahora
todo files y sockets. Un poco duro. Pregunte por el precio del
GemConnect y cri cri
Saludos
GallegO
Andres Valloud
> Time millisecondsToRun: [ 10000 timesRepeat: [ | coll | coll :=
> OrderedCollection new. 10000 timesRepeat: [ coll add: 1 ]]]
> En VAST lleva: 3453
> En VW lleva: 5712 (Sorpresivamente casi el doble...)
Me da la impresion de que esto tiene que ver con la manera de
implementar OrderedCollection... no tengo VAST a mano, podrias fijarte
en un profiler y ver que onda?
> Otra prueba boba pero para punto flotante:
> Time millisecondsToRun: [ 500000 timesRepeat: [ 10.3 * 5.7 ]]
>
> En VAST lleva: 0
> En VW lleva: 4 (otra vez me sorprendió que tarde más...)
Aca me parece que lo mas interesante seria poner un loop que tarde
aproximadamente un segundo. Por ejemplo, dependiendo de que se hace
para millisecondsToRun:, podes tener una resolucion efectiva de mas o
menos 16ms. Ademas, si justo agarras un GC etc...
Algo mas: en VAST, 10.3 es un double o un float?
Andres.
GallegO
Ahora que veo tu respuesta si, en realidad el problema mayor es no tener
un fw. de acceso a relacionales.
El problema que tenemos es que nadie puede acceder a tu base con una
herramienta típica de reporting. Esto es solucionable si uno mismo
genera vistas en otra base. Para eso se extraña no tener acceso a ODBC.
Es algo mínimo en cualquier ambiente de desarrollo. Como somos
Smalltalkers seguro podemos arreglarnos...
Ademas tenemos que tener en cuenta la reticencia que puede tener un
cliente a tener todos sus datos en una BD cerrada o propietaria a la
cual no pueden acceder por SQL.
Quizás no me exprese bien. En realidad es nuestro problema, que tenemos
una base de clientes con BD relacionales y la migración se haría
bastante complicada.
Otro tema a tener en cuenta es que quizás algunos que trabajen en
ambientes Win esten usando COM, como es nuestro caso, para generar
planillas Excel. En ese punto particular estamos pensando en hacer una
exportación en XML con el formato de Excel (ver
http://msdn.microsoft.com/en-us/library/aa140066(office.10).aspx )
No sabia que GemConnect no lo mantenían más, podrían haber hecho algo
para ODBC, se ve que ningún cliente quiere a las relacionales jaja.
Perdón en este punto quiero aclarar que no estoy contra GemStone. Al
contrario quiero usarlo. Inicie la discusión para tratar de resolver
todos los inconvenientes que vemos o creemos ver.
Saludos
GallegO
Hernan Wilkinson escribió:
Hernan Wilkinson
Buenas...
Me da la impresion de que esto tiene que ver con la manera de
> Time millisecondsToRun: [ 10000 timesRepeat: [ | coll | coll :=
> OrderedCollection new. 10000 timesRepeat: [ coll add: 1 ]]]
> En VAST lleva: 3453
> En VW lleva: 5712 (Sorpresivamente casi el doble...)
implementar OrderedCollection... no tengo VAST a mano, podrias fijarte
en un profiler y ver que onda?
Aca me parece que lo mas interesante seria poner un loop que tarde
> Otra prueba boba pero para punto flotante:
> Time millisecondsToRun: [ 500000 timesRepeat: [ 10.3 * 5.7 ]]
>
> En VAST lleva: 0
> En VW lleva: 4 (otra vez me sorprendió que tarde más...)
aproximadamente un segundo. Por ejemplo, dependiendo de que se hace
para millisecondsToRun:, podes tener una resolucion efectiva de mas o
menos 16ms. Ademas, si justo agarras un GC etc...
Algo mas: en VAST, 10.3 es un double o un float?
Andres.
Hernan Wilkinson
Hernan:
Ahora que veo tu respuesta si, en realidad el problema mayor es no tener
un fw. de acceso a relacionales.
El problema que tenemos es que nadie puede acceder a tu base con una
herramienta típica de reporting. Esto es solucionable si uno mismo
genera vistas en otra base. Para eso se extraña no tener acceso a ODBC.
Es algo mínimo en cualquier ambiente de desarrollo. Como somos
Smalltalkers seguro podemos arreglarnos...
Ademas tenemos que tener en cuenta la reticencia que puede tener un
cliente a tener todos sus datos en una BD cerrada o propietaria a la
cual no pueden acceder por SQL.
Quizás no me exprese bien. En realidad es nuestro problema, que tenemos
una base de clientes con BD relacionales y la migración se haría
bastante complicada.
Otro tema a tener en cuenta es que quizás algunos que trabajen en
ambientes Win esten usando COM, como es nuestro caso, para generar
planillas Excel. En ese punto particular estamos pensando en hacer una
exportación en XML con el formato de Excel (ver
http://msdn.microsoft.com/en-us/library/aa140066(office.10).aspx )
No sabia que GemConnect no lo mantenían más, podrían haber hecho algo
para ODBC, se ve que ningún cliente quiere a las relacionales jaja.
Perdón en este punto quiero aclarar que no estoy contra GemStone. Al
contrario quiero usarlo. Inicie la discusión para tratar de resolver
todos los inconvenientes que vemos o creemos ver.
Andres Valloud
>> Me da la impresion de que esto tiene que ver con la manera de
>> implementar OrderedCollection... no tengo VAST a mano, podrias fijarte
>> en un profiler y ver que onda?
>
> Dale, cuando tenga un rato me fijo... igual en otras cosas VW le pasa el
> trapo a VAST, solo me causo gracia encontrar una en que no.
Je... habia otra tambien... pero esa ya hace rato que la arregle :).
> Estoy de acuerdo, seguramente pasa eso. En VAST creo que maneja incrementos
> de 16ms
En Squeak 2.x me acuerdo que pasaba lo mismo... incluso a veces el
incremento era de 16k pero el resultado final era +/- 1 mod 16...
>> Algo mas: en VAST, 10.3 es un double o un float?
> Float.. en VW también por lo que vi...
Si, porque no tiene la $d final.
Andres.
Gerardo Richarte
> Varias veces se nos ocurrió escribir un driver ODBC para mostrar
> información de manera "plana" tipo BDR... nunca tuvimos tiempo, pero
> no debería ser muy complicado, solo sería de lectura.
despues, ya estoy un poco mas convencido.
Creo que la forma moderna de hacer esto es exponer una interface XML con
alguna API para acceder a la informacion (y de paso pueden decir Web 2.0)
no hay algun protocolo sttandard de red para bases relacionales? no
hay uno de esos que sea sobre XML o algo asi? no hay algun driver ODBC
con algun protocolo abierto? ideal seria implementar, directamente,
alguno de estos protocolo en Gemstone, asi despues uno se puede conectar
con algun cliente normal SQL, y no tener que dumpear todo en una base
afuera.
bueh, mis 2 centavos totalmente especulativos :)
richie
Hernan Wilkinson
GallegO
>
>
>
> Otro tema a tener en cuenta es que quizás algunos que trabajen en
> ambientes Win esten usando COM, como es nuestro caso, para generar
> planillas Excel. En ese punto particular estamos pensando en hacer una
> exportación en XML con el formato de Excel (ver
> http://msdn.microsoft.com/en-us/library/aa140066(office.10).aspx
> )
>
>
> No entiendo porque esto sería un problema con GemStone.
Por eso quiero que empecemos a generar XML (de Excel) para generar las
planillas.
Nadie tiene nada de esto hecho? mangazo mal...
Saludos
GallegO
Esteban Lorenzano
¿Para que querés la sincronización de la base de datos? Lo digo porque
en líneas generales, sincronizar a ese nivel es bastante poco
recomendable, lo más "teoricamente correcto" es integrar a nivel de
aplicación (con servicios, bah).
Insisto, lo más probable es que no tenga nada que ver con nada...
Saludos,
Esteban
Camus - El mito de Sísifo
GallegO
No entiendo bien a que te referís. Podrías darme un ejemplo mínimo
aunque sea?
Si no se trata de lo mismo por lo menos aprenderemos algo :P
Saludos
Esteban Lorenzano escribió:
Esteban Lorenzano
Yo me colgué pensando que querían replicar los datos porque quieren
integrar aplicaciones que no necesariamente están muy bien conectadas
entre sí. Esta es probablemente la inferencia errónea, porque vos en
ningún momento decís eso... pero bien, yo pensé: ¿para que querrían
duplicar datos?, 1) backup, 2) integración.
La primera opción queda descartada porque de otro modo cualquiera de
las respuestas anteriores serían factibles, entonces sigo por
integración (hay probablemente otro escenario: misma aplicación
corriendo en distintos puntos, pero se puede ver como una variante del
punto 2).
Entonces en cuanto a integración, bueno, hay varios "niveles" en donde
se puede integrar una aplicación:
1) A nivel de datos. Este es el más común, y en mi humilde opinión, el
motivo por el cual las RDBMS son tan ubicuas. Sin embargo, integrar a
nivel de datos es inherentemente malo porque se pierde toda la
inteligencia agregada en el sistema, lo cual invariablemente deviene
en redundancia de datos y redundancia de código (no sería el caso del
ultimo punto: misma aplicación corriendo en dos lugares).
2) A nivel de aplicación, la aplicación A no accede a los datos de la
aplicación B sino que usa una libreria de la aplicacion A. Es mejor
que la opcion 1 porque permite usar la inteligencia aplicada en A,
pero es negativo en otros aspectos, el mas importante es que terminas
teniendo un montón de páckages con versiones distintas por todos lados.
3) Lo que se supone que es lo mejorcito: que la aplicación A publique
un servicio y la aplicación B lo consuma. Eso, dicen, es lo mejor de
todos los mundos. Claro que es el origen de la mentira SOA que hoy
tenemos por doquier, pero eso no significa que no sea mucho mejor que
las opciones anteriores.
En definitiva, para integración, yo no pensaría en replicación de
datos sino en ver como una aplicación puede consumir servicios de otra.
En eso es en lo que estaba pensando... insisto, probablemente lejos
del problema real :)
Salud,
Esteban
GallegO
Entiendo a que te referís. Nosotros simplemente necesitamos tener la
misma aplicación corriendo en distintos lugares. El problema lo da la
mala conectividad ya que si no fuera este el caso trataríamos de
centralizar las cosas.
Aprovecho para comentar que la gente de GemStone se comunico y me
dijeron que me venden el GemConnect, pero no me dijeron que estaba
discontinuado. Que raro.
Saludos
GallegO
Esteban Lorenzano escribió:
Hernan Wilkinson
Marcelo Cortez
salu2
mdc
Jose Gregoris
Hola
Que se puede comentar sobre www.objectivity.com con respecto a Gemstone.
Alguien la uso ?
saludos kiko
|
GallegO
Sobre la licencia de u$s7000 (primer nivel no free) para GLASS se
necesita un 25% adicional para el GemConnect. De todas formas no me
suena a precio de lista, así que supongo que se puede negociar. Tampoco
me dijeron cuanto salia solamente si queríamos sumarselo a la versión
free. Yo creo que vale la pena esperar a ver si con la implementación
de FFI en GLASS portan el fw de odbc de Squeak.
Les parecen caros estos precios? Todo depende no...
Saludos
GallegO
Marcelo Cortez escribió:
> salu2
> mdc
>
> 2008/12/4 Hernan Wilkinson <hernan.w...@gmail.com
> Bueno, ojo, quizá estoy equivocado respecto del GemConnect...
>