problemas con la cache de Linqtosql

On 3 oct, 10:17, "Jes s L pez"
wrote:

Por ejemplo:

En lo malo: LINQ to SQL s lo funciona con SQL Server. Algunas cosas se han
hecho para hacerlo funcionar con otros motores, pero dudo que hayan tenido
mucho xito.

Aquí he visto algo sobre esto:

http://www.devart.com/linq/


Saludos

Hola Alfredo,

On 3 okt, 12:01, Alfredo Novoa wrote:

El Fri, 3 Oct 2008 10:17:30 +0200, Jesús López escribió:

> LINQ to SQL permite un mejor control de la concurrencia optimista.

Esto es una chorrada. La concurrencia la controla el SGBD. Lo que aporta
Linq es más complejidad innecesaria.

Por ejemplo en el caso descrito aquí:

http://msdn.microsoft.com/en-us/lib...99373.aspx

Linq lanza una excepción y hace que la actualización falle cuando en
realidad no hay ningún conflicto. Con mi BindingList este ejemplo
funcionaría perfectamente sin lanzar ningún error.

Aquí hay otro ejemplo de conflicto inexistente que además "resuelven" de
una forma absurda.

http://msdn.microsoft.com/en-us/lib...99354.aspx

El resultado lógico es: Alfred, Mary, Marketing, sin ninguna excepción ni
otras gaitas.

Obviamente no saben lo que están haciendo.

> Y un
> tratamiento más sencillo de las transacciones que con dataadatper +
> commandbuilder.

Lo único que te ahorras es no tener que asignarles una transacción a los
SqlCommand. Una mínima automatización que cualquiera se podría montar en 5
minutos en caso de que le interesase. Un detalle de muy poca importancia
comparado con todo lo demás.

> Simplemente tienes que mantener una referencia al data context, para leer y
> guardar los datos con la misma instancia.

Y con esto se te actualizan automáticamente los datos cuando se cambian
desde otra aplicación?

Si es as entonces eso está bien.

:-)
De alguna manera los ejemplos de los enlaces que has puesto
presuponen esto, pero no lo aplican. Tendría también entonces
un poco de sentido el control de la concurrencia en LINQ, aunque
tampoco sería estrictamente necesario.

Que barbaridad!

>> Es que menuda chorrada, hasta con la peor herramienta se pueden
>> desarrollar
>> proyectos con éxito,

> Lo que sí es una verdadera chorrada es decir que con un teclado con sólo un
> cero y un uno puedes desarrollar proyectos con éxito.

Si se es un "real programmer" y un machote claro que se puede :-) El
teclado de Chuck Norris solo tiene un 0 y un 1 :-)

Era una ironía, por eso llevaba la sonrisa, pero aquí no te pillan las
cosas ni aun explicándolas como en Barrio Sésamo.

Al "... reconozco que con él es posible crear con éxito aplicaciones"
solo le faltaba el famoso "... in time and within budget".
Dónde he leído/oído esto mas veces?
Es el lenguaje de los folletos de propaganda.

> Por ejemplo:

> En lo malo: LINQ to SQL s lo funciona con SQL Server. Algunas cosas se han
> hecho para hacerlo funcionar con otros motores, pero dudo que hayan tenido
> mucho xito.

La sintaxis es horrible, no permite consultar todo lo que permite SQL, no
tiene instrucciones de actualización , pretende evitar el código SQL
incrustado pero no lo consigue, obliga a definir clases inútiles, es
innecesariamente complejo, no permite trabajar con las expresiones LinQ
como si fuesen expresiones normales, solamente deja cargar en listas, no
permite definir reglas de integridad ni tablas ni vistas en la aplicación,
etc, etc. Cuanto más lo miras en detalle más fallos se ven.

Ufff! Para ya que me me va a dar un patatús.

Saludos,
Carlos

Hola Carlos,

El Sun, 5 Oct 2008 05:18:37 -0700 (PDT), Carlos M. Calvelo escribió:

Y con esto se te actualizan automáticamente los datos cuando se cambian
desde otra aplicación?

Si es as entonces eso está bien.

:-)
De alguna manera los ejemplos de los enlaces que has puesto
presuponen esto, pero no lo aplican. Tendría también entonces
un poco de sentido el control de la concurrencia en LINQ, aunque
tampoco sería estrictamente necesario.

Esto no lo entiendo muy bien. Aquí me refería al problema que tenía Juanjo
con la caché de Linq que no se le refrescaba cuando se cambiaban datos
desde otra aplicación, y no tenían que ser necesariamente cambios en la
misma fila.

Al "... reconozco que con él es posible crear con éxito aplicaciones"
solo le faltaba el famoso "... in time and within budget".
Dónde he leído/oído esto mas veces?
Es el lenguaje de los folletos de propaganda.

Pues sí, era una frase claramente "folletera" :-)

Como cuando dicen: "y con el nuevo XXX desarrollará un 40% más rápido". Sin
decir más rápido que como.

Lo que pasa es que lo del "in time and within budget" también se puede
trucar fácilmente alargando las dos cosas, y muchas veces es lo que más
conviene a las consultoras. En estos casos lo peor (para el cliente) es lo
mejor (para el proveedor), y esto explica como gente que despilfarra
recursos de mala manera puede tener una carrera exitosa.


Saludos

Hola Alfredo,

"Alfredo Novoa" wrote:

Hola Carlos,

El Sun, 5 Oct 2008 05:18:37 -0700 (PDT), Carlos M. Calvelo escribió:

>> Y con esto se te actualizan automáticamente los datos cuando se cambian
>> desde otra aplicación?
>>
>> Si es as entonces eso está bien.
>>
>
> :-)
> De alguna manera los ejemplos de los enlaces que has puesto
> presuponen esto, pero no lo aplican. Tendría también entonces
> un poco de sentido el control de la concurrencia en LINQ, aunque
> tampoco sería estrictamente necesario.

Esto no lo entiendo muy bien. Aquí me refería al problema que tenía Juanjo
con la caché de Linq que no se le refrescaba cuando se cambiaban datos
desde otra aplicación, y no tenían que ser necesariamente cambios en la
misma fila.

Me refería a la idea de que si el SGBD puede notificar a linq, o
en general a cualquier conexión (aplicación), de los cambios en los
datos ya extraidos por la misma aplicación en transacciones
anteriores, entonces casi tienen sentido los ejemplos de los enlaces
que has puesto sobre concurrencia. Entoces no habría tales
´conflictos´ (que no lo son). Pero ese control seguiría siendo
innecesario porque seguiría siendo responsabilidad del SGBD.

Saludos,
Carlos

El Sun, 5 Oct 2008 11:57:01 -0700, Carlos M. Calvelo escribió:

Me refería a la idea de que si el SGBD puede notificar a linq, o
en general a cualquier conexión (aplicación), de los cambios en los
datos ya extraidos por la misma aplicación en transacciones
anteriores, entonces casi tienen sentido los ejemplos de los enlaces
que has puesto sobre concurrencia.

Ah, eso. Pues me parece que eso sería mucho pedir para esta gente, pero
claro que sería la forma lógica de resolver las actualizaciones de los
datos en memoria, y no solo de la fila que se está editando en ese momento.

Yo eso aun lo tengo a medio implementar, pero necesito usar 3 capas y tiene
su complicación hacerlo bien. Solo funcionaría si todas las aplicaciones se
conectan al servidor intermedio y ninguna directamente a SQL Server.

Pero ese control seguiría siendo
innecesario porque seguiría siendo responsabilidad del SGBD.

Es que eso no es control de concurrencia, es simplemente como se actualizan
los datos cargados en la memoria de las aplicaciones. Control de
concurrencia optimista es lo que hace SQL Server cuando usas el nivel de
aislamiento Snapshot, y no esas chorradas.


Saludos