django-firebird backend

[maxi]

Hi,
I'm working on implementation of firebird backend for django [1]
I've an issue related of icontains filter option. Firebird uses
CONTAINING sql clause for this, which is case insesitive.

The problem is that the output generated (where clause) is wrong.
It return:

WHERE "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 advance.
--
Maxi.

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






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Override icontains filter option

[maxi]

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 method I need to override for change
this?

I followed some advice from Ramiro Morales (http://
groups.google.com.ar/group/django-developers/browse_thread/thread/
9cdcebf23491142).

The get_db_prep_lookup look like the better candidate for it, but It's
not availible on DatabaseOperations, and for lookup_cast method I have
not available the field value.
I'm a little bit lost.

I appreciated any help.

Regards





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

firebird backend for django

[maxi]

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 tests suit of
django trunk code and I found the next problem:

django is trying to execute this sql:

SELECT  "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
AS "COUNT"
FROM "AGGREGATION_BOOK"
GROUP BY "AGGREGATION_BOOK"."PRICE"
ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC

But, I get the next error:

DatabaseError: (-104, 'isc_dsql_prepare: \n  Dynamic SQL Error\n  SQL
error code = -104\n  Token unknown - line 1, column 157\n  DESC --
SELECT  "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
AS "COUNT" FROM "AGGREGATION_BOOK" 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
count field is upper case (and quoted) then  the order by clause must
be:

 ORDER BY "COUNT"  DESC

Which method can I override to solve this?
Any help?

Thanks in advance.

Maxi.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: firebird backend for django

[maxi]

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 tests suit of
> > django trunk code and I found the next problem:
>
> > django is trying to execute this sql:
>
> > SELECT  "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> > AS "COUNT"
> > FROM "AGGREGATION_BOOK"
> > GROUP BY "AGGREGATION_BOOK"."PRICE"
> > ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC
>
> > But, I get the next error:
>
> > DatabaseError: (-104, 'isc_dsql_prepare: \n  Dynamic SQL Error\n  SQL
> > error code = -104\n  Token unknown - line 1, column 157\n  DESC --
> > SELECT  "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> > AS "COUNT" FROM "AGGREGATION_BOOK" 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
> > count field is upper case (and quoted) then  the order by clause must
> > be:
>
> >  ORDER BY "COUNT"  DESC
>
> > Which method can I override to solve this?
> > Any help?
>
> > Thanks in advance.
> > 
> > Maxi.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> It comes from 
> here:http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
> in get_ordering() on the compiler.
>
> Wherever the logic is that you're uppercasing everything you'll need
> to apply it here as well.
>

Hi Alex,
Thanks for response.

 Do you think what SQLCompiler.as_sql is the right place for to do
this ?

Regards.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: firebird backend for django

[maxi]

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 doing some modifications
> >> > for work with django 1.2
> >> > Right now, I'm trying to pass some tests running the tests suit of
> >> > django trunk code and I found the next problem:
>
> >> > django is trying to execute this sql:
>
> >> > SELECT  "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> >> > AS "COUNT"
> >> > FROM "AGGREGATION_BOOK"
> >> > GROUP BY "AGGREGATION_BOOK"."PRICE"
> >> > ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC
>
> >> > But, I get the next error:
>
> >> > DatabaseError: (-104, 'isc_dsql_prepare: \n  Dynamic SQL Error\n  SQL
> >> > error code = -104\n  Token unknown - line 1, column 157\n  DESC --
> >> > SELECT  "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> >> > AS "COUNT" FROM "AGGREGATION_BOOK" 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
> >> > count field is upper case (and quoted) then  the order by clause must
> >> > be:
>
> >> >  ORDER BY "COUNT"  DESC
>
> >> > Which method can I override to solve this?
> >> > Any help?
>
> >> > Thanks in advance.
> >> > 
> >> > Maxi.
>
> >> > --
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Django developers" group.
> >> > To post to this group, send email to django-develop...@googlegroups.com.
> >> > To unsubscribe from this group, send email to 
> >> > django-developers+unsubscr...@googlegroups.com.
> >> > For more options, visit this group 
> >> > athttp://groups.google.com/group/django-developers?hl=en.
>
> >> It comes from 
> >> here:http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
> >> in get_ordering() on the compiler.
>
> >> Wherever the logic is that you're uppercasing everything you'll need
> >> to apply it here as well.
>
> > Hi Alex,
> > Thanks for response.
>
> >  Do you think what SQLCompiler.as_sql is the right place for to do
> > this ?
>
> > Regards.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> as_sql() seems like a poor place for it, because whatevers returned to
> you is already a string, you have no idea what type it us, unless in
> firebird all identifiers should be blindly uppercased.
>

Ok, I agree.

But, I'm trying to understand some things:

1).  Why if in the SELECT clause count field as defined as
COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" using "COUNT" alias
(quote and upercase), django get count (unquote and lowercase) when
add  ORDER BY count DESC

2). Where does django get the count field  (unquote and lowercase)
instead "COUNT"


Thanks for your help.

Maxi.






-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Testing django 1.5 with firebirdsql

[maxi]

Hi,

I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 
on Ubuntu 11.04 with Python 2.7
I'm working right now on a new django-firebird [1] backend which do use the 
new python firebird driver (fdb) [2].

Then, I'm running the django test suite and I get an error when it try to 
create serializers_regress_
generice928. Seem like django is trying to create a table without fields, 
like this:

'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );'

And this is not valid on Firebird. 

What does it trying to test here?
Are there any 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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/LLs-eM6Szv4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Testing django 1.5 with firebirdsql

[maxi]

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
> > I'm working right now on a new django-firebird [1] backend which do use the
> > new python firebird driver (fdb) [2].
>
> > Then, I'm running the django test suite and I get an error when it try to
> > create serializers_regress_
> > generice928. Seem like django is trying to create a table without fields,
> > like this:
>
> > 'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );'
>
> > And this is not valid on Firebird.
>
> > What does it trying to test here?
> > Are there any way to avoid (or silence) this test ?
> > Where is defined this model?
>
> Hopefully the following leads will be of some help:
>
> As per the usual Dango policy for namign DB tables (i.e. prefixed by the app
> name and then the model name) it is clear the test app is serializers_regress.
>
> it its located in:
> tests/regression_tests/serializers_regress
>
> The Django test suite test apps are actually precisely that: Django apps. So
> something you can do is to transplant them to a pristine project (copying the
> app dir, adding it to INSTALLED_APPS, etc.).
>
> Once you have that you can perform any of the actions manage.py allows you to
> do with an app. With the advantage you have only that app and there is no
> noise from the massive Django test suite:

Nice point.I was looking for some manner to just run database (orm)
related tests.

>
> For instance:
>
> * Running ./manage.py sql serializers_regress
>   To see the DDL Django+your backend generates for the app models
>
> * Running ./manage.py test serializers_regress
>   To run the tests, add -v2 to see the order in which the Django test
>   machinery creates the model tables in the test DB.
>
> Now, looking at the 'GENERICE928' part of the table name, we have another
> hint, ist corresponds to a model whose name begins (case insensitively) with
> 'generic'. A quick perusing of serializers_regress.models shows there are a
> couple of them, and in particular there is this model::
>
>     class GenericIPAddressPKData(models.Model):
>         data = models.GenericIPAddressField(primary_key=True)
>
> It has only one field, marked as the PK.
>
> Wild guess: Your backend's creation.py isn't generating the DB field
> corresponding to the (new in 1.4 IIRC) GenericIPAddressField field types
> i.e. is generating no DDL for it. And there is the origin of your
> no-fields-table DDL problem.
>

First, thank so much for your very clear response, It did help me a
lot.
The problem was, as you note, the missing definition of
GenericIPAddressField.

BTW, I've another issue related to one specific test.
In test/regressiontests/model_fields/models.py there is a model
defined as:

class BigD(models.Model):
d = models.DecimalField(max_digits=38, decimal_places=30)

Firebird doesn't accept that definitions for max_digits and
decimal_places (the max is 18)
It will be possible to add a DatabaseFeature attribute for avoid or
skip related tests?

Best Regards.
---
Maxi





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

DatabaseFeatures and supports_transactions

[maxi]

Hi,

DatabseFeatures class has a supports_transactions property for test if the 
db engine support transactions.
supports_transactions implementation makes  some metadata alters to check 
this behaivor.

Now, is really needed to do this to check transaction support? 
I don't know exactly how 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" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/J4kOjty-FHkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DatabaseFeatures and supports_transactions

[maxi]

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.
>> supports_transactions implementation makes  some metadata alters to check 
>> this behaivor.
>>
>> Now, is really needed to do this to check transaction support? 
>> I don't know exactly how 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.
>>
>>
>
Hi Karen,
 

> First, this method is used during testing, generally not during normal 
> operation. It's implemented as a cached property so regardless of how many 
> times the value is tested the underlying code which creates and drops a 
> table is only actually called once per database. Is it needed? We need to 
> know if the database actually supports transactions or if 
> commit/rollback/etc are simply no-ops. If you know of an alternative way of 
> determining this, that works across all databases, please share. I added 
> that code and I've never liked it but I don't know of another way to 
> accomplish what it needs to do.
>
>
No, I just answer because it caught my attention. Why not just trust in a 
True/False property ?
BTW, What do you mean with "commit/rollback/etc are simply no-ops" ?

I'm working on django-firebird backend implementation (now using the new 
firebird python-driver "fdb") and I need reimplement supports_transactions, 
because I need to commit any work before drop the table, otherwise, I fall 
into "Object in use" error.

Regards.
---
Maxi







 

-- 
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/-/XgRv40ktvFYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DatabaseFeatures and supports_transactions

[maxi]

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ó: 
> >> 
> >> 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. 
> >>> supports_transactions implementation makes  some metadata alters to 
> check 
> >>> this behaivor. 
> >>> 
> >>> Now, is really needed to do this to check transaction support? 
> >>> I don't know exactly how 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. 
> >>> 
> >> 
> > 
> > Hi Karen, 
> > 
> >> 
> >> First, this method is used during testing, generally not during normal 
> >> operation. It's implemented as a cached property so regardless of how 
> many 
> >> times the value is tested the underlying code which creates and drops a 
> >> table is only actually called once per database. Is it needed? We need 
> to 
> >> know if the database actually supports transactions or if 
> >> commit/rollback/etc are simply no-ops. If you know of an alternative 
> way of 
> >> determining this, that works across all databases, please share. I 
> added 
> >> that code and I've never liked it but I don't know of another way to 
> >> accomplish what it needs to do. 
> >> 
> > 
> > No, I just answer because it caught my attention. Why not just trust in 
> a 
> > True/False property ? 
>
> As I recall, the reason we can't just use a property is MySQL. There's 
> no reliable way to tell whether the database has been set up as 
> InnoDB, which supports transactions, or MyISAM, which doesn't. An 
> experimental approach allows us to be certain. 
>
> > BTW, What do you mean with "commit/rollback/etc are simply no-ops" ? 
>
> Exactly that. On databases that don't support transactions, 
> commit/rollback etc are no-ops. 
>
> > I'm working on django-firebird backend implementation (now using the new 
> > firebird python-driver "fdb") and I need reimplement 
> supports_transactions, 
> > because I need to commit any work before drop the table, otherwise, I 
> fall 
> > into "Object in use" error. 
>
> Are you saying that the current 'supports_transaction' test is leaving 
> data in an uncommitted state? From a quick eyeball, I don't see how -- 
> which bit is tripping up Firebird? Where do you need to add a commit? 
>

No, I mean if I do select * from TABLE and inmediately I try to drop the 
table whitout make a commit, the table object is still in use and then I 
gen an "Object in use" exception.

Then, I need todo 
  - select * from TABLE  <- fetch
  - commit work
  - drop TABLE

And the current implementation is:

cursor.execute('CREATE TABLE ROLLBACK_TEST (X INT)')
self.connection._commit()
cursor.execute('INSERT INTO ROLLBACK_TEST (X) VALUES (8)')
self.connection._rollback()
cursor.execute('SELECT COUNT(X) FROM ROLLBACK_TEST')
count, = cursor.fetchone()
# Commit is needed here
cursor.execute('DROP TABLE ROLLBACK_TEST')
self.connection._commit()


BTW, I was talking about it with the fdb main developer and he notes what 
there is a possible bug here about how Transaction must work.

So, if  support_transaction is the natural feature from my db engine I can 
just return True. Is Ok?


Best regards.
---
Maxi


-- 
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/-/H88VFE55n-YJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DatabaseFeatures and supports_transactions

[maxi]

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 during testing, generally not during normal 
>>> operation. It's implemented as a cached property so regardless of how many 
>>> times the value is tested the underlying code which creates and drops a 
>>> table is only actually called once per database. Is it needed? We need to 
>>> know if the database actually supports transactions or if 
>>> commit/rollback/etc are simply no-ops. If you know of an alternative way of 
>>> determining this, that works across all databases, please share. I added 
>>> that code and I've never liked it but I don't know of another way to 
>>> accomplish what it needs to do.
>>>
>>>
>> No, I just answer because it caught my attention. Why not just trust in a 
>> True/False property ?
>> BTW, What do you mean with "commit/rollback/etc are simply no-ops" ?
>>
>>
> We have no single value we can set for this property for MySQL; whether 
> that DB supports transactions is dependent on the configuration of the DB 
> server. If the MySQL server is configured to use the MyISAM storage engine, 
> then all transaction methods such as commit and rollback simply do nothing 
> (are no-ops).
>  
>
>> I'm working on django-firebird backend implementation (now using the new 
>> firebird python-driver "fdb") and I need reimplement supports_transactions, 
>> because I need to commit any work before drop the table, otherwise, I fall 
>> into "Object in use" error.
>>
>
> That seems odd. What does "object in use" mean? The routine is currently 
> coded to:
>
> 1 - create table
> 2 - commit #1
> 3 - insert row into table
> 4 - rollback #3
> 5 - select count of rows in table
> 6 - read result of #5
> 7 - drop the table
>  
> You need to commit before #7? Doesn't seem like that should be necessary. 
> Can you elaborate on why Firebird thinks it is necessary?
>

Yes, I need to commit before 7 because the transaction is still active in 
that point.

cursor.execute('SELECT COUNT(X) FROM ROLLBACK_TEST')
count, = cursor.fetchone()
self.connection.commit()  # <-- I need add this.
cursor.execute('DROP TABLE ROLLBACK_TEST')
self.connection._commit()

cursor.execute start a new transaction, but cursor.fetchone() does not 
close it. Then I need a explicit commit, otherwise, drop table will fail 
because the table is still in use for the current active transaction.





-- 
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/-/TSaDbzruc6gJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

URLField definition on creation.py

[maxi]

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 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/-/AYLfKNgCEC4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URLField definition on creation.py

[maxi]

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 group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django 1.3: running test suit

[maxi]

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
    ''
  File "/home/maxi/projects/django/django/django/test/testcases.py",
line 530, in assertQuerysetEqual
return self.assertEqual(map(transform, qs), values)
AssertionError: Lists differ: ['

- ['']
? ^

+ ['',
? ^

+  '']


I was looking into test_compress_format_loading function and I see
what try to load fixture4.json

Into fixture4.json I just have 1 object defined:

[
{
"pk": "6",
"model": "fixtures.article",
"fields": {
"headline": "Django pets kitten",
"pub_date": "2006-06-16 16:00:00"
}
}
]


Of course, the test fail.

Then, my question is
Is Ok what this test fail ?
What I'm doing wrong ?

Thanks in advance.
---
Maxi.






-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.3: running test suit

[maxi]

On 25 mar, 16:44, Paul McMillan  wrote:
> We can't help you if you don't tell us a bit more about your system.
> What version of Python? What OS?

I'm running django 1.3 from trunk. I'm using Ubuntu 10.04 and python
2.6.5

>Is there anything else unusual about
> your system or how you are running the tests?
>

Mmm... yes there are something unusual.
I'm testing the django-firebird backend and trying (or working hard)
to run, at least, so many backend related test as I can.
Yes, I know what firebird sql is not supported out the box with django
but there 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 Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.3: running test suit

[maxi]

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 than something is wrong with
> your initial_data fixture loading.
>
>     - Gabriel

Hi Gabriel,
Thank for response.

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):
  File "/home/maxi/projects/django/django/django/core/management/
commands/loaddata.py", line 174, in handle
obj.save(using=using)
  File "/home/maxi/projects/django/django/django/core/serializers/
base.py", line 165, in save
models.Model.save_base(self.object, using=using, raw=True)
  File "/home/maxi/projects/django/django/django/db/models/base.py",
line 553, in save_base
result = manager._insert(values, return_id=update_pk, using=using)
  File "/home/maxi/projects/django/django/django/db/models/
manager.py", line 195, in _insert
    return insert_query(self.model, values, **kwargs)
  File "/home/maxi/projects/django/django/django/db/models/query.py",
line 1436, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
  File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
django-firebird/firebird/compiler.py", line 114, in execute_sql
cursor = super(SQLCompiler, self).execute_sql(None)
  File "/home/maxi/projects/django/django/django/db/models/sql/
compiler.py", line 735, in execute_sql
cursor.execute(sql, params)
  File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
django-firebird/firebird/base.py", line 231, in execute
return self.cursor.execute(cquery, params)
DatabaseError: (-530, u'isc_dsql_execute: \n  violation of FOREIGN KEY
constraint "CONTACT_ID_REFS_ID_48084965" on table
"AGGREGATION_BOOK"\n  Foreign key reference target does not exist --
INSERT INTO "AGGREGATION_BOOK" ("ID", "ISBN", "NAME", "PAGES",
"RATING", "PRICE", "CONTACT_ID", "PUBLISHER_ID", "PUBDATE") VALUES (1,
159059725, The Definitive Guide to Django: Web Development Done Right,
447, 4.5, 30.00, 1, 1, 2007-12-06)')


Here, the problem seems to be what is trying to insert
aggregation.book contact_id (which refers to Author model)  before to
insert aggregation.author.

In initial_data.json aggregation.author data come after to
aggregation.book which violate the referencial integrity.

Is it an error or I'm doing something wrong?

Thanks for you help.





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.3: running test suit

[maxi]

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 than something is wrong
> > with
> > > your initial_data fixture loading.
>
> > >     - Gabriel
>
> > Hi Gabriel,
> > Thank for response.
>
> > 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):
> >  File "/home/maxi/projects/django/django/django/core/management/
> > commands/loaddata.py", line 174, in handle
> >    obj.save(using=using)
> >  File "/home/maxi/projects/django/django/django/core/serializers/
> > base.py", line 165, in save
> >    models.Model.save_base(self.object, using=using, raw=True)
> >  File "/home/maxi/projects/django/django/django/db/models/base.py",
> > line 553, in save_base
> >    result = manager._insert(values, return_id=update_pk, using=using)
> >  File "/home/maxi/projects/django/django/django/db/models/
> > manager.py", line 195, in _insert
> >    return insert_query(self.model, values, **kwargs)
> >  File "/home/maxi/projects/django/django/django/db/models/query.py",
> > line 1436, in insert_query
> >    return query.get_compiler(using=using).execute_sql(return_id)
> >  File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
> > django-firebird/firebird/compiler.py", line 114, in execute_sql
> >    cursor = super(SQLCompiler, self).execute_sql(None)
> >  File "/home/maxi/projects/django/django/django/db/models/sql/
> > compiler.py", line 735, in execute_sql
> >    cursor.execute(sql, params)
> >  File "/home/maxi/projects/django/django-firebird/forks/bitbucket/
> > django-firebird/firebird/base.py", line 231, in execute
> >    return self.cursor.execute(cquery, params)
> > DatabaseError: (-530, u'isc_dsql_execute: \n  violation of FOREIGN KEY
> > constraint "CONTACT_ID_REFS_ID_48084965" on table
> > "AGGREGATION_BOOK"\n  Foreign key reference target does not exist --
> > INSERT INTO "AGGREGATION_BOOK" ("ID", "ISBN", "NAME", "PAGES",
> > "RATING", "PRICE", "CONTACT_ID", "PUBLISHER_ID", "PUBDATE") VALUES (1,
> > 159059725, The Definitive Guide to Django: Web Development Done Right,
> > 447, 4.5, 30.00, 1, 1, 2007-12-06)')
>
> > Here, the problem seems to be what is trying to insert
> > aggregation.book contact_id (which refers to Author model)  before to
> > insert aggregation.author.
>
> > In initial_data.json aggregation.author data come after to
> > aggregation.book which violate the referencial integrity.
>
> > Is it an error or I'm doing something wrong?
>
> > Thanks for you help.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> This problem looks similar to one we see under MySQL InnoDB becaue it
> doesn't properly support deferred constraints.
>

Hi Alex,

Yes, that seems to be the problem. Firebird doesn't support deferred
constraints.
Are there any approach or workaround to solve this ?




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[maxi]

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 are a few fixes for v1.6.x Release Candidate 1 commited into 
>> master
>> 
>> Fixed missing date_interval_sql implementation. #21
>> Fixed datetime_trunc_sql NotImplementedError. #20
>> Fixed missing SQLDateTimeCompiler. #19
>> Fixed BigIntegerField is not supported in introspection. #18
>> Fixed BinaryField is not supported in introspection. #17
>> Fixed missing method name. #11
>> Fixed setup.py due to README extension change. #12
>> 
>>
>> Also Django Firebird stable 1.5.2 is 
>> uploaded to 
>> pypi with a few fixes 
>> backported
>>  from 
>> master branch (if you use Django 1.5.x)
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b8c9ecb9-f7ec-4654-87ef-ae3143ae3286%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

django-firebird backend: migrations and NULL fields

[maxi]

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:


if null:
sql += " NULL"<-- Here
else:
sql += " NOT NULL"

I just need:
if not null:
sql += " NOT NULL"


Is the correct approach rewrite the column_sql method? Are there other 
approach?

Regards.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e9f2-a5bf-4e13-b7c1-0a08abd18a4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.