django-firebird backend: migrations and NULL fields

Hi, I'm trying to implement the new schema migration of django 1.7 for django-firebird backend. In column_sql method, when the field can be null, in firebird, is not necessary add the NULL keyword. So to change this behavior I need override the entire column_sql method just to change one line:

Re: Firebird backend for Django 1.6.x is updated (RC state)

El miércoles, 12 de febrero de 2014 15:11:33 UTC-3, Florian Apolloner escribió: > > Nice, can you also upload wheel packages? > Done! For now, just for the stable version (django-firebird with django 1.5 support) > > On Wednesday, February 12, 2014 2:19:11 PM UTC+1, mariuz wrote: >> >> Here

Re: URLField definition on creation.py

Ok, then, what about SlugField? Is not the same case? Regards. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/FQMFohktYdsJ. To post to this grou

URLField definition on creation.py

I was seeing that the new URLField [1] is just defined on oracle backend (into creation.py) Why not in other backend modules? Best Regards. --- Maximiliano Robaina django-firebird backend maintainer. [1] https://docs.djangoproject.com/en/dev/ref/models/fields/#urlfield -- You received this me

Re: DatabaseFeatures and supports_transactions

El martes, 25 de septiembre de 2012 21:01:39 UTC-3, Karen Tracey escribió: > > On Tue, Sep 25, 2012 at 11:24 AM, maxi >wrote: > >> El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey >> escribió: >> >>> First, this method is used duri

Re: DatabaseFeatures and supports_transactions

El martes, 25 de septiembre de 2012 20:57:54 UTC-3, Russell Keith-Magee escribió: > > On Tue, Sep 25, 2012 at 11:24 PM, maxi > > wrote: > > > > > > El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey > escribió: > >> > >

Re: DatabaseFeatures and supports_transactions

El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey escribió: > > On Mon, Sep 24, 2012 at 10:15 PM, maxi >wrote: > >> Hi, >> >> DatabseFeatures class has a supports_transactions property for test if >> the db engine support transactions. >

DatabaseFeatures and supports_transactions

many times this supports_transactions is called but I think what it produce unnecessary alterations in database structure, or I'm misinterpreting how it supposed works. --- Maxi -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: Testing django 1.5 with firebirdsql

Hi Ramiro, On Sep 13, 9:17 pm, Ramiro Morales wrote: > Hi Maxi, > > > > > On Thu, Sep 13, 2012 at 8:20 PM, maxi wrote: > > Hi, > > > I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 on > > Ubuntu 11.04 with Python 2.7 > &

Testing django 1.5 with firebirdsql

way to avoid (or silence) this test ? Where is defined this model? Thanks in advance. --- Maxi [1] The old one use kinterbasdb [2] http://pypi.python.org/pypi/fdb/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Django 1.3: running test suit

On 25 mar, 20:22, Alex Gaynor wrote: > On Fri, Mar 25, 2011 at 7:20 PM, maxi wrote: > > On 25 mar, 19:21, Gabriel Hurley wrote: > > > The extra object is in the initial_data.json fixture which is loaded > > > automatically. If you're not seeing that object

Re: Django 1.3: running test suit

e. I see now what I have an error when try to load modeltests/aggregation/ fixtures/initial_data.json This is the traceback: Problem installing fixture '/home/maxi/projects/django/django/tests/ modeltests/aggregation/fixtures/initial_data.json': Traceback (most recent call last): Fi

Re: Django 1.3: running test suit

e are many firebird users who would like to use both. Anyway, there are something strange, because the json file just have one object and the test compare with two. What am I misinterpreting ? Best regards. -- Maxi -- You received this message because you are subscribed to the Goog

Django 1.3: running test suit

Hi, I've running (or trying) the django 1.3 test suite and I've got an error with the next traceback... Traceback (most recent call last): File "/home/maxi/projects/django/django/tests/modeltests/fixtures/ tests.py", line 221, in test_compress_format_loading '

Re: firebird backend for django

On 23 jul, 18:58, Alex Gaynor wrote: > On Fri, Jul 23, 2010 at 4:56 PM, maxi wrote: > > > On 23 jul, 18:42, Alex Gaynor wrote: > >> On Fri, Jul 23, 2010 at 4:30 PM, maxi wrote: > >> > Hi, > > >> > I'm working on django-firebird project and

Re: firebird backend for django

On 23 jul, 18:42, Alex Gaynor wrote: > On Fri, Jul 23, 2010 at 4:30 PM, maxi wrote: > > Hi, > > > I'm working on django-firebird project and doing some modifications > > for work with django 1.2 > > Right now, I'm trying to pass some tests running the t

firebird backend for django

GROUP BY "AGGREGATION_BOOK"."PRICE" ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC') The problem is with the count field on ORDER BY clause. The sql is defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the

Override icontains filter option

Hi, I need to change the normal behavior for icontains filter option (for django-firebird backend implementation). For icontains filter, django add automatically an '%' but, for case insensitive search, firebird uses the CONTAINING statement which doesn't need % Then, the question is, which m

django-firebird backend

ERE "TABLE"."FIELD" CONTAINING %value% And, the correct form should be: WHERE "TABLE"."FIELD" CONTAINING ' value ' It is using % instead ' The question is, which method I have to touch to change this behavior? Thanks in