] > blog entries (CubicWeb's Forge)

blog entries

CubicWeb 3.7 released

2010/03/19 by Alexandre Fayolle

Hi there !

I'm pleased to announce the 3.7 release of CubicWeb, after a much shorter development cycle than for the 3.6...

But it still have some interesting changes:

  • NOW DEPENDS ON PYTHON 2.5
  • use the newly created logilab.database package (you'll have to install it as well as upgrade logilab.common and rql)
  • proper behaviour on the repository side of cubiweb:
    • dropped unsafe_execute, execute is now unsafe by default in hooks and operations. You can still explicitly control security using the enabled_secury context manager
    • proper transaction hooks control using the hooks_control context manager
  • started some transaction undo support (only undo of deletion supported right now)
  • various other bug fixes and improvments

Notice the 3.6 branch will still be maintained for some time.

Enjoy!


MS SQL Server backuping gotcha

2010/01/19 by Alexandre Fayolle

While working on the port of CubicWeb to the Windows platform, including supporting MS Sql Server as the database backend, I got bitten by a weird behavior of that database engine. When working with cubicweb, most administrations command are wrappped by the cubicweb-ctl utility and database backups are performed by running cubicweb-ctl db-dump <instancename>. If the instance uses PostgreSQL as the backend, this will call the pg_dump utility.

When porting to Sql Server, I could not find such a utility, but I found that Transact SQL has a BACKUP DATABASE command, so I was able to call it using Python's pyodbc module. I tested it interactively, and was satisfied with the result:

>>> from logilab.common.db import get_connection
>>> cnx = get_connection(driver='sqlserver2005', database='mydb', host='localhost', extra_args='autocommit;trusted_connection')
>>> cursor = cnx.cursor()
>>> cursor.execute('BACKUP DATABASE ? TO DISK = ?', ('mydb', 'C:\\Data\\mydb.dump'))
>>> cnx.close()

However, testing that very same code through cubicweb-ctl produced no file in C:\\Data\\. To make a (quite) long story short, the thing is that the BACKUP DATABASE command is asynchronous (or maybe the odbc driver is) and the call to cursor.execute(...) will return immediately, before the backup actually starts. When running interactively, by the time I got to type cnx.close() the backup was finished but when running in a function, the connection was closed before the backup started (which effectively killed the backup operation).

I worked around this by monitoring the size of the backup file in a loop and waiting until that size gets stable before closing the connection:

import os
import time
from logilab.common.db import get_connection

filename = 'c:\\data\\toto.dump'
dbname = 'mydb'
cnx = get_connection(driver='sqlserver2005',
                     host='localhost',
                     database=dbname,
                     extra_args='autocommit;trusted_connection')
cursor = cnx.cursor()
cursor.execute("BACKUP DATABASE ? TO DISK= ? ", (dbname, filename,))
prev_size = -1
err_count = 0
same_size_count = 0
while err_count < 10 and same_size_count < 10:
    time.sleep(1)
    try:
        size = os.path.getsize(filename)
        print 'file size', size
    except OSError, exc:
        err_count +=1
        print exc
    if size > prev_size:
        same_size_count = 0
        prev_size = size
    else:
       same_size_count += 1
cnx.close()

I hope sharing this will save some people time...

Note: get_connection() comes from logilab.common.db which is a wrapper module which tries to simplify writing code for different database backends by handling once for all various idiosyncrasies. If you want pure pyodbc code, you can replace it with:

from pyodbc import connect
cnx = connect(driver='SQL Server Native Client 10.0',
              host='locahost',
              database=dbname,
              trusted_connection='yes',
              autocommit=True)

The autocommit=True part is especially important, because BACKUP DATABASE will fail if run from within a transaction.


Using gettext on windows

2009/12/01 by Alexandre Fayolle
http://www.gnu.org/graphics/gnu-head-sm.jpg

CubicWeb relies on gnu gettext for its translation management. However, the binary installers easily found for gettext (such as the one in python(x,y)) are for older versions, and compiling it is not that easy (especially in the Python world where people do not necessarily have a C compiler at hand).

We did the job and a binary installer for gnu gettext 0.17 is available on our ftp server.


Running CubicWeb on Windows

2009/09/08 by Alexandre Fayolle

This was not supported (and still isn't officially). But rumors have been circulating about a port of CubicWeb on Windows.

http://pc-astuces.seebz.net/images/logo-windows-small.jpg

I can confirm that there is some truth in this. A few changesets have been circulating, to be merged in the official repository any time now, enabling one to run CubicWeb on Windows. Support for running CubicWeb as a Windows service is not available yet, but should become available in the next few weeks.

Update: check out the source of the 3.5 branch, and you will be able to create and start instances on Windows. Use cubicweb-ctl start -D for non daemon start.


News from Europython 2009

2009/07/02 by Alexandre Fayolle
http://www.europython.eu/images/europython_logo.png

Nicolas gave a talk at Europython2009 about CubicWeb. Reinout Van Rees posted his notes about the talk on his blog. Thanks Reinout. You may also read Nicolas' slides and watch his lightning talk.