Firebird SQL: Estado del driver para python

El driver python para Firebird SQL es fue históricamente kinterbasdb (KDB) [0] de hecho, el único que había hasta el momento. Desde hace ya un tiempo se está desarrollando un reemplazo del mismo con el nombre de FDB [1], el cual está en un estado de estabilidad importante. Acá los principales puntos que lo diferencian:

  1. KDB es implementado usando una mezcla de C/C++ y Python mientras que FDB es un módulo Python puro usando la librería cliente de Firebird via ctypes. Esto tiene varias consecuencias a saber, KDB no funciona con Python 3 u otra implementación que no sea CPython, mientras que FDB soporta Python 2 y 3, y puede potencialmente correr sobre otras implementaciones Python con el módulo ctypes.
  2. KDB soporta Firebird e Interbase desde la versión 1. FDB solamente soporta Firebird 2.0 y superior.
  3. FDB continúa la interface de KDB y se mantienen funcionalmente tan cerca como sea posible, excepto en partes que son especificas de la implementación y compatibilidad con versiones existente. Por ejemplo, FDB usa un sistema mucho más simple de Traducción Dinámica de Tipos (Dynamic Type Translation) que KDB.
  4. La funcionalidad principal debería ser idéntica o equivalente entre ambos pero algunas características son implementadas *ligeramernte* diferentes en FDB (diferente API), por ejemplo, Transacciones Distribuidas.
  5. FDB implementa algúnas caracteristicas que KDB no, porque estas son más actuales, como soporte para Trace Service, nbackup service, etc.

Entonces, para que caso es mejor uno que otro?

KDB es necesario cuando querés trabajar con con Interbase o Firebird 1.x

FDB es necesario cuando querés usar Python 3 o algunas de las nuevas características de Firebird 2.5, y podría ser más sencillo (al menos esa es la intención) trabajar con éste.

¿Cuál es mejor para usar en nuevos proyectos ?

Depende del criterio de estabilidad inmediata. Ahora mismo, se podría decir que KDB es más “estable” que FDB pero, desde un punto de vista a largo plazo, FDB es la elección correcta. Es posible comenzar con KDB y reemplazar este más tarde con FDB, dado que las diferencias entre estos son realmente pequeñas y están bien aisladas.

Por otro lado, el desarrollo de KDB está detenido y no habrá nuevas versiones del mismo. Acá [2] se pueden ver todos los detalles de porque está detenido y porqué FDB comenzó como reemplazo del mismo.

Update:

Hay un tercer participante que olvide mencionar: pyfirebirdsql [4]

La característica más destacada de éste es que es un driver “puro python”, es decir, no necesita un compilador C ni la librería cliente de firebird. Además fue desarrollado desde el principio con python 3 en mente.

——

[0] http://www.firebirdsql.org/file/documentation/drivers_documentation/python/3.3.0/index.html

[1] http://pypi.python.org/pypi/fdb/

[2] http://web.firebirdsql.org/index.php?op=devel&sub=python

[4] https://github.com/nakagami/pyfirebirdsql

Ref: http://thread.gmane.org/gmane.comp.db.firebird.python/185/focus=187

Linux TV

Ok, mi Tele tiene linux. Y ahora?

Hacking!

2012 Resolutions. Part 1.

I don’t know if call this resolutions or maybe wishes for the next year, but I’ll try to acomplish, at least one:

1. django-firebird: update to django 1.3

2. Implement my modifications to south for firebird support.

3. Build a web based firebird manager (like ibWebAdmin) on top of django.

4. Help to test pyfirebirdsql and analyze a possible replacement of kinterbasedb into django-firebird.

Ok, this is only referred to open source projects.

PyCon Argentina 2011 - Junin

afiche

Tercer conferencia internacional sobre el lenguaje de programación python.

PyConAr 2011

Se viene la 3er conferencia internacional de Python en Argentina, organizada por el grupo de usuarios pyar. Más información en http://pyconar.blogspot.com/

pyconar-banner

django y base de datos heredadas

En un proyecto en el que estamos trabajando, el cual básicamente consiste en migrar una aplicación de escritorio a un entorno web, decidimos mantener la herramienta que venimos usando justamente para todo lo que sea desarrollo web, es decir, django.

Ahora, el tema con django es simple cuando se empieza un proyecto desde cero, pero en este caso, ya heredamos la base de datos con la que debemos trabajar y por lo tanto tenemos que atarnos a esto. Además, la base de datos que debemos utilizar es Firebird SQL ( si, firebird :) ), y django no dispone de soporte “out the box” para este motor de base de datos, pero por suerte hay un grupito de gente (autobombo)[1]  que se interesa por dar este soporte ;) y por lo tanto tenemos un módulo que nos permite trabajar con django y firebird.

Uno de los primeros temas que se nos planteó al tener que usar una base de datos legacy, es con el tipo de datos Boolean.
Firebird, al igual que otros motores de base de datos SQL, no tiene un tipo de datos nativo que represente un Boolean, es decir, que permita trabajar con valores True o False.
Si bien esto no es un inconveniente ya que en estos caso se reemplaza por un tipo de datos que permite almacenar, por ejemplo, un valor entero (1 = True, 0 = False) o un valor de tipo caracter, que era nuestro caso el cual utiliza el valor “S” para verdadero (true) y “N” para falso (false).

Django dispone de un tipo de datos para soporte de Booleans y como no todos los motores de base de datos soportan True y False (por ej, MySQL para el cual django tiene soporte “de fabrica”, tampoco tiene un dato nativo boolean y por lo tanto se implementa generalmente como un Smallint con los valores 1 y 0 para True / False respectivamente), pero por defecto trabaja con valores 1 y 0.

¿Cómo hacemos entonces para usar los valores S y N heredados como si fuesen booleans nativos?

Herencia al rescate.!

No me voy a poner a explicar como se hace en django para escribir tipos de campos personalizados. La documentación de django es muy completa y explica todo al respecto.

http://docs.djangoproject.com/en/1.2/howto/custom-model-fields/

Pero si quería exponer como quedó nuestra implementación de BooleanField, al cual llamamos en un arranque furioso de creatividad, BoolField.

class BoolField(models.BooleanField):
    __metaclass__ = models.SubfieldBase

    def db_type(self, connection):
        return “CHAR(1) NOT NULL CHECK (%s IN (’S’,’N’))”
   
    def get_prep_value(self, value):
        if value:
            return u’S’
        return u’N’
   
    def to_python(self, value):
        if isinstance(value, basestring):
            if value.strip() == ‘S’:
                return True
            return False
        return value


Y con esto, ya tenemos nuestro BooleanField ala Firebird.


[1] http://code.google.com/p/django-firebird/

Por qué elegir python

Hace un par de años atrás (fines de 2009) un cliente de españa al cual le ofrezco servicios de outsourcing, me envió un mail solicitandome mi punto de vista para el reemplazo de su herramienta de desarrollo: Delphi 6.

Acá expongo entonces los fragmentos principales de mi respuesta y mi opinión sobre por que elegir python como herramienta de desarrollo de software.

DISCLAIMER: hay que tener en cuenta que este mail lo escribí hace 2 años atrás donde además expuse pensamientos sobre investigaciones que hacía 4 o 5 años antes (2005-2006) inclusive.

Hace un tiempo, digamos unos 3 años (en realidad fue un poco más, quizás 5 años pero decididamente hace 3), empecé a buscar alternativas a Delphi. Por un montón de cosas: el lenguaje no evolucionaba, la incertidumbre de que iba a pasar con la herramienta, si seguia Borland o no, etc. Entonces empecé a buscar herramientas (más precisamente un lenguaje de programación) que cumplan con la siguiente características:

1. Que sea multiplataforma: que me permita ejecutar mi programa tanto en Windows como en Linux sin cambiar nada o al menos muy poco.
2. Que sea open source: quiero poder ver como esta hecha, y si fuese necesario, mejorarla y/o adaptarla a mi necesidades sin restricciones de licencias.
3. Influenciado por el punto anterior (2), que tenga una buena comunidad de usuarios que la respalden.
4. Que pueda hacer desarrollos tanto de aplicaciones de escritorio, como aplicaciones web sin tener que aprender otro lenguaje.
5. Un lenguaje de programación que sea intuitivo y permita un rápido desarrollo, que sea fácil de aprender. Es decir, que sea productivo, que acorte los tiempos de desarrollo.
6. Que tenga una buena base de librerías para desarrollar y sobre todo completa: (acceso a base de datos, mails, tratamiento de imagenes, etc.)

Primeramente, empece viendo Java: supongo que porque tiene mucho marketing, hay empresas grandes atrás de este producto. Me conseguí un par de libros, hice un curso básico inicial, traté de hacer alguna que otra cosa más o menos productiva, etc. Conclusión: no me gustó, si para hacer un pequeño programita que imprima “Hola mundo” tengo que escribir más de 10 líneas no me parece muy productivo. Java es muyyyyy grande hay un monton de cosas, ni hablar de que para hacer aplicaciones de tipo empresariales hay que saber usar Java EE que es un mundo aparte. Además de los recursos necesarios para ejecutar una aplicación en Java, por ejemplo un entormo de desarrollo como NetBeans necesitas por lo menos 2 GB de memoria (para una aplicación medianamente grande) y aún así le cuesta.

En el transcurso de mi incursión por Java, también vi .NET, más precisamente C#. Más de lo mismo, mucho código para hacer poco. Quería algo más consiso. El lenguaje (C#) en sí tiene cosas muy interesantes, pero es muy parecido a Java. Y bueno, solo me permitiría usarlo en Windows, no era lo que buscaba. (hay una implementación de .NET para Linux que se llama Mono, pero no se que empuje le pueda dar Microsoft a esto). También el punto de que .NET es de Microsoft y por lo tanto no es Libre. No contemplaba varios de los puntos que expuse anteriormente.

Finalmente caí en Python, bueno no, mentira, primero en Ruby influenciado por el framework Ruby on Rails que es para desarrollo web y que tiene mucha publicidad últimamante (de hecho hay un “Delphi” para Ruby que se llama 3rdRail) . Lo probé un tiempo pero luego lo abandoné, quizás más por falta de tiempo o poque había algo que no me convencia del todo.
Entonces, como decía, empece a ver Python, tenía casi todo lo que buscaba:
- Multiplataforma: sin cambiar una línea de código funcionaba perfecto tanto en Linux como en Windows (salvo que hagas cosas especificas de la plataforma). Es más tambien corre en Mac OSX (el sistema operativo de Apple). De hecho python viene por defecto en todas las distribuciones de Linux.
- Es libre-open source: tiene una gran comunidad que lo respalda.
- Es super fácil de aprender y por lo tanto super productivo. Por su característica de ser muy expresivo es muy fácil de enteder lo que el programador quiere poner en el código, casí como si fuese pseudocódigo.
- Tiene una gran librería estandar (así como Delphi viene con la VCL): pero creo yo, mucho más completa que la de Delphi.
- Poder hacer una aplicación de escritorio o una aplicación web muy fácil y rápido sin tener que aprendar nada nuevo del lenguaje (salvo aprender el framework que resuelva el problema en cuestión).
- En fin, un lenguaje muy completo, de muy alto nivel. Un programador con un poco de experiencia, en 15 días más o menos, ya lo tiene aprendido lo principal

Ahora, no es la pancea, hay cosas que no son para hacer con Python (o al menos no directemente), pero si para todo lo que yo buscaba en ese momento.
Por ejemplo, con respecto al acceso a base de datos: hice un sistema para una entidad del gobierno (un seguro materno infantil de salud)  todo hecho con python.  El framework que use para base de datos me permite, solo tocando un parámetro, usar  Firebird, Oracle, SQL Server, MySQL, etc. practicamente cualquiera. Hoy uso Firebird  pero si mañana quiero usar Oracle: creo toda  la estructura de base de datos en Oracle, migro los datos y a mi aplicación solo le digo que ahora se va a conectar a un motor Oracle, no programo una línea.

Bueno, no me voy a poner a explicar las caracteristicas del lenguaje acá porque no termino más :D pero acá van algunas referencias:

http://es.wikipedia.org/wiki/Python

http://www.python.org/
http://www.python.org/about/
http://www.python.org/about/success/

Y por sobre todo esto:  ¿Quién usa Python?

Google ( y lo usa mucho) - You tube
Yahoo
N.A.S.A.
IBM
Disney
The US Navy
Nokia.
Washington Post (washingtonpost.com)
http://popego.com/
etc, etc, etc…

http://pythonology.org/success

Tags: python delphi

frostbyte.com.ar Blog en hosting gratis. Fail !

Como mencione en el primer post, el primer intento de tener mi blog terminó fallando. ¿Y cuál fue el problema?

En realidad no es que haya habido un problema, creo que lo que no estuvo bien fue la solución elegida para mi necesidades. Veamos…

Posibilidades para tener un blog:

1. Usar un servicio de blog como blogger, wordpress.com, tumblr, etc  [0]

2. Contratar un hosting e implementar directamente ahí la herramienta. La mayoría de los hostings ya vienen con instaladores de blogs y cms.

4. Tener nuestro propio web server :D

3. Usar un hosting gratis (mi caso)

5. ¿Otros?

El problema con un hosting gratis es que generalmente tienen algunas restricciones o imposiciones, como por ejemplo te tenés que comer que te inyecten banners.

En mi caso particular estuve usando www.000webhost.com/  que no está tan mal lo que ofrecen en el servicio free y además la respuesta de soporte fueron bastante rápidas, no te meten publicidad y características de administración bastante completas. Pero lo que pasa en con este hosting, bah, en realidad con la mayoría de los que son gratis es que si tu sitio tiene poco o casi ninguna actividad, te lo dan de baja. Ah, y además NO TE AVISAN ! por lo tanto perdés todo lo que tenías alojado en el mismo.

Conclusión: Como frostbyte.com.ar tenía casi cero (0) actividad me lo dieron de baja y perdí mi blog.

Ajá!  y los backups? Bueno, esto es otro tema :(

Trataré de ir completando esta entrada de manera que vaya quedando documentada la experiencia.

[0] de hecho ahora estoy usando tumblr.com

Hello Word !! and a new hope

Despues de haber intentado (y fracasado rotundamente) tener mi blog en un hosting propio, cosa de la que comentaré en algún otro momento, voy a probar tumblr.

Lo que vi hasta ahora parace bastante interesante, sobre todo lo que refiere a no tener que preocuparse en demasia por la configuración del blog. Quizás parezca más un twitter con esteroides, con menos restricciones ¿?, pero bueno veamos…

Intentaré (nuevamente) mantener fluidez en las publicaciones.

See you.