Re: django-firebird backend: migrations and NULL fields

[Maximiliano Robaina]

El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió:
>
> Let's go with a feature for this then. 
>
> Maxi, did you want to submit a patch, or do you want me to add it at some 
> point next week!
>
> Andrew
>

I'll appreciate if you can add it.
BTW, are there other areas that need some work, for instance, add_field 
method [1], if I try to delete a default value on a column that does not 
have a previous default value definition I get an error on firebird, for 
which reason, I need to check if that field has got defined a default value 
before.
Then I need to rewrite add_field method too.
I think, for not to delay django 1.7 release, I'll do some workaround and 
I'll try to send you a pull request or a patch with some proposal later.

[1] 
https://github.com/django/django/blob/master/django/db/backends/schema.py#L401


Best regards.
 

>
>
> On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> For what it’s worth, I recently added a feature to add “FROM DUAL” where 
>> Oracle needs it.
>>
>> This looks roughly similar. Maybe we could use the same approach. (I 
>> didn’t look closely.)
>>
>> -- 
>> Aymeric.
>>
>>
>>  
>> On 14 mai 2014, at 17:06, Andrew Godwin > 
>> wrote:
>>
>> Hmm, I'm not sure about adding more features, but it might be cleaner...
>>
>> Andrew
>>
>>
>> On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck 
>> > wrote:
>>
>>> How about adding a flag to Operations? implied_null, perhaps.
>>> On May 14, 2014 7:52 AM, "Andrew Godwin" > 
>>> wrote:
>>>
 Hi,

 That's currently the only approach I'm afraid - there's an open issue 
 (raised by Shai Berger I believe) that column_sql should be broken down 
 into more component pieces so it can be more easily changed, but that's a 
 difficult task to do and not something I want to go and change completely 
 as we're trying to release 1.7.

 What we could do is change those NULL and NOT NULL strings to be 
 defined on the schema editor class itself, and then you could set 
 sql_null_suffix = "" or similar - do you think that would be a reasonable 
 approach?

 Andrew


 On Wed, May 14, 2014 at 7:05 AM, maxi 
 > wrote:

> 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-develop...@googlegroups.com .
> To post to this group, send email to 
> django-d...@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.
>


 -- 
 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-develop...@googlegroups.com .
 To post to this group, send email to 
 django-d...@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/CAFwN1upTtLEmGjz5f2vUBV6kEFDqdiyRyz4GhM3i3WbSyot0aw%40mail.gmail.com
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>>> 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-develop...@googlegroups.com .
>>> To post to this group, send email to 
>>> django-d...@googlegroups.com
>>> .
>>> Visit this group at http://groups.google.com/group/django-developers.
>

Re: Database-dependant tests and third-party backends

[Maximiliano Robaina]

El miércoles, 7 de mayo de 2014 14:18:25 UTC-3, Shai Berger escribió:
>
> Hi, 
>
> On Wednesday 07 May 2014 19:40:08 Aymeric Augustin wrote: 
> > 
> > I'm trying to make the lives of maintainers of third-party database 
> > backends a bit easier. 
> > 
>
> +1. 
>
> > 
> > *1) Checking database features* 
> > 
> > This is the correct solution for database-dependant tests in general. 
> > 
>
> In most cases, it is. But in some cases, you need to differentiate on 
> severely 
> idiosyncratic behaviors, which defy attempts to define them as anything 
> but 
> "behaves like MySql". 
>
> > *What do you think of adding feature flags that have the same value for 
> all 
> > core backends but may be set to a different value by third-party 
> backends?* 
> > 
> > With a comment explaining which backends use the flag and what it does, 
> I 
> > find it acceptable. Then we would skip some tests based on the flag. 
> > 
>
> Sounds good to me, 
>
> > *2) Checking connection.vendor* 
> > 
> > This is often inferior to feature flags. 
> > 
> > Positive checking ("run this test only for SQLite") is reasonable. At 
> > worst, the test is skipped on third-party databases where it could pass. 
> > 
> > Negative checking ("run this test on all databases except Oracle") is 
> more 
> > problematic. If a third-party backend also fails the test, there's no 
> easy 
> > way to ignore it. 
> > 
> > Conditional code ("do X for vendors A, B and C, do Y for other vendors") 
> is 
> > also problematic. All third-party backends will do Y, which may or may 
> not 
> > be the right behaviour. 
> > 
> > *Would you object to adding "microsoft" to explicit checks for 
> > connection.vendor where appropriate?* 
> > 
>
> That seems ugly to me, unless we actually add a core backend for SQL 
> Server. 
> It feels like adding a dependency on 3rd-party projects. 
>
> I suggest, instead, that we solve the problem for real (so even Firebird 
> can 
> enjoy it): Remove all vendor checks except for positive checking. Replace 
> conditional code with either conditions on feature flags, or refactoring 
> into 
> separate test functions; and replace negative checks by an API allowing 
> the 
> backends to filter the tests. So, instead of a test saying "I'm not 
> running on 
> Oracle", let Oracle say "I'm not running these tests". 
>
> This is much more work, but gives a much nicer result. Also, it should be 
> part 
> of the larger work -- a formal database backend API. 
>
>
I agree, I think this is much more cleaner approach.

Also, there are some specific features (at less in firebird), which cause 
test fail, for instance, test/regressiontests/model_fields/models.py, the 
BigD model max_digits 38 and decimal_places = 30 are not supported by 
firebird, 
So, how can I skip this test?  Would have to ask them to add one new 
database feature flag? I don't think that this be the correct approach.

-- 
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/8a752c74-1076-44c8-9a39-582ce05d78f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database-dependant tests and third-party backends

[Maximiliano Robaina]

El miércoles, 7 de mayo de 2014 22:03:11 UTC-3, Russell Keith-Magee 
escribió:
>
>
> On Thu, May 8, 2014 at 12:40 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> I'm trying to make the lives of maintainers of third-party database 
>> backends a bit easier.
>>
>  
> +1. Very much in support of this as a general principle.
>  
>
>> I'm specifically interested in MSSQL backends. Unlike Oracle, it isn't 
>> supported by Django out of the box, but it's a very common database. The 
>> most robust implementation, django-mssql, is very close to passing Django's 
>> entire test suite in addition to its own test suite.
>>
>> Currrently Django uses two solutions for database-dependant tests, both 
>> of which would require small adjustments to support third-party backends 
>> adequately.
>>
>> *1) Checking database features*
>>
>> This is the correct solution for database-dependant tests in general.
>>
>> *What do you think of adding feature flags that have the same value for 
>> all core backends but may be set to a different value by third-party 
>> backends?*
>>
>> With a comment explaining which backends use the flag and what it does, I 
>> find it acceptable. Then we would skip some tests based on the flag.
>>
>
> From a purely technical perspective, this is the right approach AFAICT.
>  
> The catch is at a project management level. By doing this, we're 
> introducing code branches, but our own testing won't be able able to 
> execute the "other" branch, so our release testing coverage will be 
> deficient. From a testing perspective, this makes me a little nervous, as 
> we're essentially relying on third party backend providers to (a) tell us 
> which flags are needed (b) when/where then need to be applied, and (c ) to 
> respond in a timely fashion during the release process to make sure the 
> flags are all up to date.
>
> *2) Checking connection.vendor*
>>
>> This is often inferior to feature flags.
>>
>> Positive checking ("run this test only for SQLite") is reasonable. At 
>> worst, the test is skipped on third-party databases where it could pass.
>>
>> Negative checking ("run this test on all databases except Oracle") is 
>> more problematic. If a third-party backend also fails the test, there's no 
>> easy way to ignore it.
>>
>> Conditional code ("do X for vendors A, B and C, do Y for other vendors") 
>> is also problematic. All third-party backends will do Y, which may or may 
>> not be the right behaviour.
>>
>> *Would you object to adding "microsoft" to explicit checks for 
>> connection.vendor where appropriate?*
>>
>
> I'm less convinced this is a good idea. Vendor flags were introduced as 
> part of the introduction of unittest2 to Django's core. In retrospect, the 
> role being played by 'vendor' should probably implemented as a specific 
> feature. There might be a light documentation benefit from having 
> backend.vendor, but I'm not convinced we should be leaning on it heavily 
> for testing purposes, and I'm definitely not convinced adding references to 
> vendors that aren't part of Django's official codebase is a good idea. 
>
> The good news here is that your PR #2640 seems to bear this out.
>
> While we're on the subject of providing better support to third party 
> backends - I've floated this idea in the past, but now seems an opportune 
> time to discuss again: I'd like to be able to expand our testing 
> infrastructure to include automated testing of projects that are 
> significant to the community. Database backends are particularly relevant 
> here, but things like DDT, Django-registration, and django-rest-framework 
> probably also fall under this umbrella. The idea here would be:
>
>  1) to give us (as the core team) better visibility when we make a change 
> that is going to have an big impact on the community
>  2) to ensure that the community knows what libraries in the ecosystem 
> have been updated when we release a new Django version
>  3) to provide some guidance to the community that these are the packages 
> you should be paying attention to - the "first amongst equals" of the 
> broader third party app ecosystem.
>
> I know this isn't a small project. However, we have a good opportunity to 
> get the ball rolling next week :-)
>  
>

+1
 

-- 
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/790b2644-e0cd-4c98-be78-592b2ab078cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Schema tests: delete_tables

[Maximiliano Robaina]

Hi,

Running tests, (I'm using firebird) in schema app, I see that the tearDown 
method deletes all tables created by each test. The problem here is for 
tables with AutoInc field where sequences are created independently,  when 
the table is dropped we need delete the sequence object too.
The, to me, customized delete_model method from schema editor do that, when 
the model is deleted, then the sequence is deleted if any.

So, the delete_tables method used in tearDown, needs to delete the 
correlated sequences either calling to drop_sequence_sql from 
DatabaseOperations or implementing something in Schema editor.


---
Maxi

-- 
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/1b7ca4ce-6cc6-4191-9b6a-dc61ec3d717e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Schema tests: delete_tables

[Maximiliano Robaina]

Hi Michel,

Thank to explain it better than me.

Regards.

El martes, 20 de mayo de 2014 00:42:35 UTC-3, Michael Manfre escribió:
>
> Hi Russell,
>
> I understand what Maximiliano is asking. It's a flaw with 
> SchemaTests.delete_tables [1] and it is essentially doing a raw drop table, 
> instead of using the 3rd party backend friendly SchemaEditor.delete_model 
> [2]. There was the last time I checked (and still exists) a lot of raw SQL 
> in the schema tests that caused tests to fail for django-mssql. It appears 
> other non-core backends are also facing these issues.
>
> Regards,
> Michael Manfre
>
> [1] 
> https://github.com/django/django/blob/stable/1.7.x/tests/schema/tests.py#L38
> [2] 
> https://github.com/django/django/blob/stable/1.7.x/django/db/backends/schema.py#L274
>
>
> On Mon, May 19, 2014 at 10:45 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina 
>> 
>> > wrote:
>>
>>> Hi,
>>>
>>> Running tests, (I'm using firebird) in schema app, I see that the 
>>> tearDown method deletes all tables created by each test. The problem here 
>>> is for tables with AutoInc field where sequences are created independently, 
>>>  when the table is dropped we need delete the sequence object too.
>>> The, to me, customized delete_model method from schema editor do that, 
>>> when the model is deleted, then the sequence is deleted if any.
>>>
>>> So, the delete_tables method used in tearDown, needs to delete the 
>>> correlated sequences either calling to drop_sequence_sql from 
>>> DatabaseOperations or implementing something in Schema editor.
>>>
>>> Hi Maximiliano,
>>
>> It's not clear (to me, at least) what you're asking for here. 
>>
>> In the general case, resetting sequences *shoudn't* be needed as part of 
>> a test suite. Tests that are dependent on a specific PK value being 
>> allocated are wrong by design, because you simply can't guarantee 
>> allocation order in a database.
>>
>> If you've got a specialist sequence being used as a part of a particular 
>> model, then you might need to have some custom code to reset particular 
>> sequences… but then, you're dealing with a custom scenario, in which case I 
>> don't think it's unreasonable to require some custom reset code as part of 
>> your test.
>>
>> If this is a Firebird specific issue, then it isn't clear to me why the 
>> statements you need can't be integrated into the flushing infrastructure 
>> that is already in place. In all the built-in backends, the tearDown method 
>> on tests doesn't *delete* tables, it flushes them; sequences are reset as 
>> part of that process. If Firebird requires something extra, you're going to 
>> need to give us a specific proposal for a database API modification that 
>> would meet your needs. 
>>
>> Yours,
>> Russ Magee %-)
>>  
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/1e76f781-48b3-4ae2-b2de-3e3f8d0e21f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Schema tests and .extra queryset method

[Maximiliano Robaina]

Hi,

Running schema tests I caught an issue, more precisely, 
in test_add_field_default_transform.
At the end, this test method is doing:

self.assertEqual(Author.objects.extra(where=["thing = 1"]).count(), 2)

The problem here is what in this where clause, the "thing" field must be 
quoted.

In firebird :

SELECT * FROM AUTHOR WHERE thing = 1   <-- Here thing (in lowercase) 
and THING (in uppercase) are equivalent, are the same object

is different of:
   
SELECT * FROM AUTHOR WHERE "thing" = 1   <--  field is quoted

For a more generic test I think we need to avoid use .extra method or 
another raw sql statement.





-- 
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/1d03c3b7-8f8e-4794-97bc-73cfcb699d07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Schema tests and .extra queryset method

[Maximiliano Robaina]

El miércoles, 21 de mayo de 2014 21:06:22 UTC-3, Russell Keith-Magee 
escribió:
>
> Hi Maximiliano,
>
> Thanks for letting us know. If you find a problem like this, the best way 
> to report it is to open a ticket in Trac. That way we have a permanent 
> record of the existence of the issue, and we can mark the issue as resolved 
> when a fix is applied to the source tree. It also allows us to flag and 
> triage specific issues so that we know they get addressed before a release.
>
> Yours,
> Russ Magee %-)
>

Done! 
https://code.djangoproject.com/ticket/22683#ticket



 

>
>
> On Thu, May 22, 2014 at 6:38 AM, Maximiliano Robaina 
> 
> > wrote:
>
>> Hi,
>>
>> Running schema tests I caught an issue, more precisely, 
>> in test_add_field_default_transform.
>> At the end, this test method is doing:
>>
>> self.assertEqual(Author.objects.extra(where=["thing = 1"]).count(), 2)
>>
>> The problem here is what in this where clause, the "thing" field must be 
>> quoted.
>>
>> In firebird :
>>
>> SELECT * FROM AUTHOR WHERE thing = 1   <-- Here thing (in lowercase) 
>> and THING (in uppercase) are equivalent, are the same object
>>
>> is different of:
>>
>> SELECT * FROM AUTHOR WHERE "thing" = 1   <--  field is quoted
>>
>> For a more generic test I think we need to avoid use .extra method or 
>> another raw sql statement.
>>
>>
>>
>>
>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/1d03c3b7-8f8e-4794-97bc-73cfcb699d07%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/1d03c3b7-8f8e-4794-97bc-73cfcb699d07%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/fa541d6a-56c7-4d52-816e-40c84b388e6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Schema tests and .extra queryset method

[Maximiliano Robaina]

El jueves, 22 de mayo de 2014 03:24:12 UTC-3, Shai Berger escribió:
>
> Hi Maximiliano, 
>
> The issue of case in quoted and un-quoted names in SQL is indeed a sad 
> mess, 
> bad decisions made in the 1960s that we still need to live with today. 
>
> On Wednesday 21 May 2014 15:38:57 Maximiliano Robaina wrote: 
> > 
> > self.assertEqual(Author.objects.extra(where=["thing = 1"]).count(), 2) 
> > 
> > The problem here is what in this where clause, the "thing" field must be 
> > quoted. 
> > 
> > In firebird : 
> > 
> > SELECT * FROM AUTHOR WHERE thing = 1   <-- Here thing (in lowercase) 
> > and THING (in uppercase) are equivalent, are the same object 
> > 
> > is different of: 
> > 
> > SELECT * FROM AUTHOR WHERE "thing" = 1   <--  field is quoted 
> > 
>
> Quoting it uncoditionally would break the test on Oracle (which, by 
> default, 
> turns all the names to uppercase). There is a feature-flag for it... 
>

How this feature flag should works?
I see that Oracle backend is always making an upper in 
DatabaseOperations.quote_name, therefore, how does Oracle pass test like 
[1] where it is using field name in lowecase [2] ?

[1] https://github.com/django/django/blob/1.7b4/tests/schema/tests.py#L152
[2] https://github.com/django/django/blob/1.7b4/tests/schema/tests.py#L172


 

>
> > For a more generic test I think we need to avoid use .extra method or 
> > another raw sql statement. 
>
> ...but I agree -- an "extra" should not be needed at all in this specific 
> test. 
> The Author model has the added column as a field. 
>
> Shai. 
>

-- 
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/adadfd6d-143c-42dc-85e3-af38fcbd21b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Schema tests and test_foreign_key_index_long_names_regression

[Maximiliano Robaina]

Hi,

I'm trying to figured out how the 
test_foreign_key_index_long_names_regression method works.
For my (using firebird backend)  this test fails with:
   
   AssertionError: u'author_foreign_key_with_rea7ef8' not found in {u'ID': 
{'unique': False, 'primary_key': True}}

I see that It's using get_indexes to check if a foreign key field exist as 
index, but get_indexes returns a different information

What am I doing wrong here or am I misinterpreting something wrong?


---
Maxi

-- 
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/b3fbb833-d48d-4687-8e45-28b9bfb5fbb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Schema tests and test_foreign_key_index_long_names_regression

[Maximiliano Robaina]

I answer to myself.
The implementation of DatabaseIntrospection.get_indexes in django-firebird 
is so old, It come from of the first version. I fixed it and It works fine 
now.
I was confusing because I was seeing the implementation of oracle backend 
and  also seem like It retrieves just primary key and uniques.


El viernes, 6 de junio de 2014 20:45:55 UTC-3, Maximiliano Robaina escribió:
>
> Hi,
>
> I'm trying to figured out how the 
> test_foreign_key_index_long_names_regression method works.
> For my (using firebird backend)  this test fails with:
>
>AssertionError: u'author_foreign_key_with_rea7ef8' not found in {u'ID': 
> {'unique': False, 'primary_key': True}}
>
> I see that It's using get_indexes to check if a foreign key field exist as 
> index, but get_indexes returns a different information
>
> What am I doing wrong here or am I misinterpreting something wrong?
>
>
> ---
> Maxi
>

-- 
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/7474cc6c-dc74-49b3-a2c5-97c9b7eedd9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 3rd-party database backends: Do you need a "can_introspect_null" feature flag?

[Maximiliano Robaina]

El martes, 17 de junio de 2014 07:26:03 UTC-3, Rahul escribió:
>
> DB2 backend can introspect the nullability correctly, but it can't 
> introspect BooleanField. 
>
> It introspect Boolean field as SmallIntegerField but in the test case if 
> can_introspect_boolean_field=False then it checks only for IntegerField. By 
> including introspect_boolean_field_as_smallInteger and 
> introspect_boolean_field_as_Integer feature flag can eliminate this 
> problem. 
>

+1
Same in Firebird 

-- 
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/cfe42820-8da7-4554-ad2f-be27dd750946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird backend: migrations and NULL fields

[Maximiliano Robaina]

El martes, 20 de mayo de 2014 09:27:48 UTC-3, Andrew Godwin escribió:
>
> Yes, I'm aware add_field is also in need of expansion points - the same 
> issue was raised with the MSSQL backend too.
>
> I'm more than happy to add these in now or after 1.7 in a point release; 
> the actual implementation of those methods is private so we can change it 
> around a little (or at least, we can add to the available overrides; I 
> wouldn't go removing those things on backend implementers like yourself).
>
> I've also added the implied_column_null database feature in this commit: 
> https://github.com/django/django/commit/1b07781292c2cef9367b521dc0f2b40f4d363083
>
> Just set it to True and you should get the behaviour you need.
>
> Andrew
>


Hi Andrew,

Are you going to backport this to version 1.7?


 

>
>
> On Fri, May 16, 2014 at 10:00 PM, Maximiliano Robaina  > wrote:
>
>>
>>
>> El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió:
>>
>>> Let's go with a feature for this then. 
>>>
>>> Maxi, did you want to submit a patch, or do you want me to add it at 
>>> some point next week!
>>>
>>> Andrew
>>>
>>
>> I'll appreciate if you can add it.
>> BTW, are there other areas that need some work, for instance, add_field 
>> method [1], if I try to delete a default value on a column that does not 
>> have a previous default value definition I get an error on firebird, for 
>> which reason, I need to check if that field has got defined a default value 
>> before.
>> Then I need to rewrite add_field method too.
>> I think, for not to delay django 1.7 release, I'll do some workaround and 
>> I'll try to send you a pull request or a patch with some proposal later.
>>  
>> [1] 
>> https://github.com/django/django/blob/master/django/db/backends/schema.py#L401
>>
>>
>> Best regards.
>>  
>>
>>>
>>>
>>> On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin >> polytechnique.org> wrote:
>>>
>>>> For what it’s worth, I recently added a feature to add “FROM DUAL” 
>>>> where Oracle needs it.
>>>>
>>>> This looks roughly similar. Maybe we could use the same approach. (I 
>>>> didn’t look closely.)
>>>>
>>>> -- 
>>>> Aymeric.
>>>>
>>>>
>>>>  
>>>> On 14 mai 2014, at 17:06, Andrew Godwin  wrote:
>>>>
>>>> Hmm, I'm not sure about adding more features, but it might be cleaner...
>>>>
>>>> Andrew
>>>>
>>>>
>>>> On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck  wrote:
>>>>
>>>>> How about adding a flag to Operations? implied_null, perhaps.
>>>>> On May 14, 2014 7:52 AM, "Andrew Godwin"  wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> That's currently the only approach I'm afraid - there's an open issue 
>>>>>> (raised by Shai Berger I believe) that column_sql should be broken down 
>>>>>> into more component pieces so it can be more easily changed, but that's 
>>>>>> a 
>>>>>> difficult task to do and not something I want to go and change 
>>>>>> completely 
>>>>>> as we're trying to release 1.7.
>>>>>>
>>>>>> What we could do is change those NULL and NOT NULL strings to be 
>>>>>> defined on the schema editor class itself, and then you could set 
>>>>>> sql_null_suffix = "" or similar - do you think that would be a 
>>>>>> reasonable 
>>>>>> approach?
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>> On Wed, May 14, 2014 at 7:05 AM, maxi  wrote:
>>>>>>
>>>>>>> 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 += "

Firebird - Schema migrations: add or alter field

[Maximiliano Robaina]

Hi folks,

I'm here again trying to up to date the django-firebird backend.
The last stable version was for django 1.8 LTS, that came to end of life, 
so I want to update to 1.11 LTS first  and then to 2.0.

Having said that, one of unresolved things is about  adding a non-nullable 
field to a populated table, in this case Firebird seems to work differently 
than others sql engines. 
If I have to update data over a recently added field (actually django does 
this adding a default value and removing this afterward), I need commit the 
alter table command first then, populate the new field with the provide 
default value. [1]
Firebird doesn't allow updates/inserts to use objects created in the same 
transaction (in this case the column) because DDL is actually only really 
executed/completed at transaction commit.

Then, What do you think is the best approach to achieve this?
Is necessary to rewrite the context maneger interface of 
BaseDatabaseSchemaEditor?
Maybe a new hook to run command after the metadata update finish?

Regards.


[1] Here there's a discussion about this
https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/130739

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4752f38a-d821-4a17-90a3-bb6d2621cc72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django-firebird test expressions

[Maximiliano Robaina]

Hi,

Testing expressions test app, the query generated into 
BasicExpressionsTests.test_annotate_values_filter method:

companies = Company.objects.annotate(
foo=RawSQL('%s', ['value']),
).filter(foo='value').order_by('name')

Generate:

'SELECT  "EXPRESSIONS_COMPANY"."ID", "EXPRESSIONS_COMPANY"."NAME", 
"EXPRESSIONS_COMPANY"."NUM_EMPLOYEES", "EXPRESSIONS_COMPANY"."NUM_CHAIRS", 
"EXPRESSIONS_COMPANY"."CEO_ID", 
"EXPRESSIONS_COMPANY"."POINT_OF_CONTACT_ID", ? AS "FOO" FROM 
"EXPRESSIONS_COMPANY" WHERE ? = ? ORDER BY "EXPRESSIONS_COMPANY"."NAME" ASC'

This sql command has 3 params (?), two of which are out of where clause.

? AS "FOO" 

WHERE ? = ?


So, the underlying database driver execute this, doing something like this

 cursor.execute(sql, ['value', 'value', 'value'])

Is correct that the 3 params are replaced into the entire sql and not just 
on where clause ?
It depend of the  implementation on each database driver?

Best regards
Maxi


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5570530d-696d-4f6e-b557-eb84be410661%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird test expressions

[Maximiliano Robaina]

Hi Josh,

Thanks for response.

El domingo, 15 de abril de 2018, 20:35:54 (UTC-3), Josh Smeaton escribió:
>
> It looks correct to me. RawSQL is defining a parameter to be included in 
> the query. The RawSQL expression itself is used in the select and on the 
> left hand side of the WHERE clause, so the parameter needs to be included 
> there. The right hand side of the WHERE clause is a regular string (which 
> just happens to also be named "value") which Django will always 
> parameterise and has nothing to do with the RawSQL expression itself.
>
> Is there some reason you think there's an issue with the SQL being 
> constructed?
>

No, I don't think that the sql statement is wrong. I just traying to 
figured out how the sql is generated by Django and why it fails in Firebird.
I found the answere, of course, there is a Firebird limitation on this type 
of statement. Running that query raise a "Data type unknown" error.

https://stackoverflow.com/questions/37348807/data-type-unknown-in-case-expression-with-only-parameters-as-values

I will need to found other strategy to resolve this.

Regards.

 

>
> On Sunday, 15 April 2018 12:25:48 UTC+10, Maximiliano Robaina wrote:
>>
>> Hi,
>>
>> Testing expressions test app, the query generated into 
>> BasicExpressionsTests.test_annotate_values_filter method:
>>
>> companies = Company.objects.annotate(
>> foo=RawSQL('%s', ['value']),
>> ).filter(foo='value').order_by('name')
>>
>> Generate:
>>
>> 'SELECT  "EXPRESSIONS_COMPANY"."ID", "EXPRESSIONS_COMPANY"."NAME", 
>> "EXPRESSIONS_COMPANY"."NUM_EMPLOYEES", "EXPRESSIONS_COMPANY"."NUM_CHAIRS", 
>> "EXPRESSIONS_COMPANY"."CEO_ID", 
>> "EXPRESSIONS_COMPANY"."POINT_OF_CONTACT_ID", ? AS "FOO" FROM 
>> "EXPRESSIONS_COMPANY" WHERE ? = ? ORDER BY "EXPRESSIONS_COMPANY"."NAME" ASC'
>>
>> This sql command has 3 params (?), two of which are out of where clause.
>>
>> ? AS "FOO" 
>>
>> WHERE ? = ?
>>
>>
>> So, the underlying database driver execute this, doing something like this
>>
>>  cursor.execute(sql, ['value', 'value', 'value'])
>>
>> Is correct that the 3 params are replaced into the entire sql and not 
>> just on where clause ?
>> It depend of the  implementation on each database driver?
>>
>> Best regards
>> Maxi
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45683c0b-6dcd-4207-a8e3-d4b578c42bd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird test expressions

[Maximiliano Robaina]

Hi Shai,

Thank for the tip

El martes, 17 de abril de 2018, 3:01:30 (UTC-3), Shai Berger escribió:
>
> Hi Maximiliano, 
>
> On Sat, 14 Apr 2018 19:25:48 -0700 (PDT) 
> Maximiliano Robaina > wrote: 
>
> > Hi, 
> > 
> > Testing expressions test app, the query generated into 
> > BasicExpressionsTests.test_annotate_values_filter method: 
> > 
> > companies = Company.objects.annotate( 
> > foo=RawSQL('%s', ['value']), 
> > ).filter(foo='value').order_by('name') 
> > 
> > Generate: 
> > 
> > 'SELECT  "EXPRESSIONS_COMPANY"."ID", "EXPRESSIONS_COMPANY"."NAME", 
> > "EXPRESSIONS_COMPANY"."NUM_EMPLOYEES", 
> > "EXPRESSIONS_COMPANY"."NUM_CHAIRS", "EXPRESSIONS_COMPANY"."CEO_ID", 
> > "EXPRESSIONS_COMPANY"."POINT_OF_CONTACT_ID", ? AS "FOO" FROM 
> > "EXPRESSIONS_COMPANY" WHERE ? = ? ORDER BY 
> > "EXPRESSIONS_COMPANY"."NAME" ASC' 
> > 
> > This sql command has 3 params (?), two of which are out of where 
> > clause. 
> > 
> > ? AS "FOO" 
> > 
> > WHERE ? = ? 
> > 
>
> A few years ago something similar was causing issues with the Oracle 
> backend. To resolve it, Mariusz added a clevar hack, relying on named 
> parameters -- he made sure that if the same parameter value is used 
> more than once, then the statement re-uses the parameter name, passing 
> the value only once. So, in your case, the equivalent would be 
> something like 
>
> ... 
> "EXPRESSIONS_COMPANY"."POINT_OF_CONTACT_ID", %arg1 AS "FOO" FROM 
> "EXPRESSIONS_COMPANY" WHERE %arg1 = %arg1 ORDER BY 
> "EXPRESSIONS_COMPANY"."NAME" ASC' 
>
> with 
>
>  cursor.execute(sql, [], arg1='value') 
>
> This was relatively easy to do in the Oracle backend, which has always 
> used named parameters under the hood (though the idea to do it was, in 
> my opinion, surprising and brilliant). If Firebird supports them, you 
> may be able to borrow this solution. 
>
> Shai 
>

Ok, but it is a cx_Oracle implementation.
Unfortunately fdb (the firebird python driver) doesn't support this and, in 
any case, is a FirebirdSQL limitation. [1]

Regards.


[1]  
https://stackoverflow.com/questions/37348807/data-type-unknown-in-case-expression-with-only-parameters-as-values

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/306f8e3e-6ed2-4e7c-a8d2-b8d3798d463e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird test expressions

[Maximiliano Robaina]

El martes, 17 de abril de 2018, 9:11:23 (UTC-3), Josh Smeaton escribió:
>
> Have you looked into using Cast for this particular query to see if it 
> passes?
>
> https://docs.djangoproject.com/en/2.0/ref/models/database-functions/#cast
>
> Cast(RawSQL('%s', ['value']), CharField(max_length=10) ?
>
> If that worked, then perhaps you could find a clever way to wrap problem 
> expressions, or at least document the workaround for your users.
>

Ok, it worked rigth. It is a good started point and solve the problem. 
I will need to dig a little more to found out a better solution.

Thanks.






 

>
> On Tuesday, 17 April 2018 21:12:09 UTC+10, Maximiliano Robaina wrote:
>>
>>
>> Hi Shai,
>>
>> Thank for the tip
>>
>> El martes, 17 de abril de 2018, 3:01:30 (UTC-3), Shai Berger escribió:
>>>
>>> Hi Maximiliano, 
>>>
>>> On Sat, 14 Apr 2018 19:25:48 -0700 (PDT) 
>>> Maximiliano Robaina  wrote: 
>>>
>>> > Hi, 
>>> > 
>>> > Testing expressions test app, the query generated into 
>>> > BasicExpressionsTests.test_annotate_values_filter method: 
>>> > 
>>> > companies = Company.objects.annotate( 
>>> > foo=RawSQL('%s', ['value']), 
>>> > ).filter(foo='value').order_by('name') 
>>> > 
>>> > Generate: 
>>> > 
>>> > 'SELECT  "EXPRESSIONS_COMPANY"."ID", "EXPRESSIONS_COMPANY"."NAME", 
>>> > "EXPRESSIONS_COMPANY"."NUM_EMPLOYEES", 
>>> > "EXPRESSIONS_COMPANY"."NUM_CHAIRS", "EXPRESSIONS_COMPANY"."CEO_ID", 
>>> > "EXPRESSIONS_COMPANY"."POINT_OF_CONTACT_ID", ? AS "FOO" FROM 
>>> > "EXPRESSIONS_COMPANY" WHERE ? = ? ORDER BY 
>>> > "EXPRESSIONS_COMPANY"."NAME" ASC' 
>>> > 
>>> > This sql command has 3 params (?), two of which are out of where 
>>> > clause. 
>>> > 
>>> > ? AS "FOO" 
>>> > 
>>> > WHERE ? = ? 
>>> > 
>>>
>>> A few years ago something similar was causing issues with the Oracle 
>>> backend. To resolve it, Mariusz added a clevar hack, relying on named 
>>> parameters -- he made sure that if the same parameter value is used 
>>> more than once, then the statement re-uses the parameter name, passing 
>>> the value only once. So, in your case, the equivalent would be 
>>> something like 
>>>
>>> ... 
>>> "EXPRESSIONS_COMPANY"."POINT_OF_CONTACT_ID", %arg1 AS "FOO" FROM 
>>> "EXPRESSIONS_COMPANY" WHERE %arg1 = %arg1 ORDER BY 
>>> "EXPRESSIONS_COMPANY"."NAME" ASC' 
>>>
>>> with 
>>>
>>>  cursor.execute(sql, [], arg1='value') 
>>>
>>> This was relatively easy to do in the Oracle backend, which has always 
>>> used named parameters under the hood (though the idea to do it was, in 
>>> my opinion, surprising and brilliant). If Firebird supports them, you 
>>> may be able to borrow this solution. 
>>>
>>> Shai 
>>>
>>
>> Ok, but it is a cx_Oracle implementation.
>> Unfortunately fdb (the firebird python driver) doesn't support this and, 
>> in any case, is a FirebirdSQL limitation. [1]
>>
>> Regards.
>>
>>
>> [1]  
>> https://stackoverflow.com/questions/37348807/data-type-unknown-in-case-expression-with-only-parameters-as-values
>>
>>  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a378e035-d12e-473c-8da1-d6f1190ce3b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Schema alter_field - check constraints

[Maximiliano Robaina]

Hi,

Digging into schema migration code (and updating this to work with Firebird 
[1]) I see in _alter_field method [2] a validation for  Change check 
constraints?
Of course, this fails related to the test method 
"test_alter_field_default_dropped" because in Firebird check contraints are 
table based and not column based.
Then, there is a feature property "supports_column_check_constraints", now 
the question is Should not we use that feature to validate if is necessary 
check the number of check constraints?

If supports_column_check_constraints is False no validation is necessary, 
right?


Regards

[1] https://github.com/maxirobaina/django-firebird
[2] 
https://github.com/django/django/blob/4660ce5a6930e07899ed083801845ee4c44c09df/django/db/backends/base/schema.py#L593

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1f16ac9b-7d6c-450e-a662-9aa616271a78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

can_introspect_default feature

[Maximiliano Robaina]

Hi,

How supposed to can_introspect_default must work?

I'm working on django firebird backend and I'm trying to figured out how 
this feature works, but the schema tests fails. 
This default is at database level or django level?

If I define a field with a default value, and do a metadata introspection 
over this field to know if default value is defined, it always returns True.

I hope be clear (sorry for my bad english)

---
Maxi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/24d65283-5bca-4253-8365-1f2b2d5a3307%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: can_introspect_default feature

[Maximiliano Robaina]

Hi Tim,

Thanks for response.

El martes, 18 de octubre de 2016, 12:07:34 (UTC-3), Tim Graham escribió:
>
> Hi Maxi,
>
> Did you take a look at the relevant commit that introduced the flag?
>
> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc
>

Yes, I was looking into this changeset, but I can't understand yet what 
"And that the default is no longer set in the database." means in 
test_add_field_default_dropped [1].
field.default contains the column default definition not the default value 
of the some table record, Is it that correct?, So, why this must be None?



[1] 
https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc#diff-888b45a0a8f38ee67e8d22403cf994dbR1371


Regards 



>
> On Tuesday, October 18, 2016 at 9:51:46 AM UTC-4, Maximiliano Robaina 
> wrote:
>>
>> Hi,
>>
>> How supposed to can_introspect_default must work?
>>
>> I'm working on django firebird backend and I'm trying to figured out how 
>> this feature works, but the schema tests fails. 
>> This default is at database level or django level?
>>
>> If I define a field with a default value, and do a metadata introspection 
>> over this field to know if default value is defined, it always returns True.
>>
>> I hope be clear (sorry for my bad english)
>>
>> ---
>> Maxi
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f2e735f6-967e-4391-8623-48c1f7e7d3b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.8 - django 1.7 differences to read DecimalField

[Maximiliano Robaina]

Hi,


I'm the maintener of django-firebird database backend.

I've an strange behavior (a different result) when reading a value from a 
DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured 
out where is my mistake.

I've a django project which I update from 1.7 to 1.8.
In this project I've a model with a DecimalField.  (by example, price 
= DecimalField(max_digits=18, decimal_places=2)

Then, in django 1.7

>> obj = ModelWithDecimalField.objects.first()
>> obj.price
>>  Decimal("1990.00")

In django 1.8

>> obj = ModelWithDecimalField.objects.first()
>> obj.price
>>  Decimal("1990")


So, I don't know where look to found this change. What change between 1.7 
and 1.8
Maybe I forget to implement something in django-firebird 1.8


Thanks in advance
Maxi






-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33cca19c-edc1-4ff1-a8d8-10f0db5a87c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.8 - django 1.7 differences to read DecimalField

[Maximiliano Robaina]

Hi Tim,

Thanks for the tip.

I finally found the problem [1], which was obviously between the chair and 
the keyboard.

Regards.
Maxi

[1] https://github.com/maxirobaina/django-firebird/issues/69


El miércoles, 5 de abril de 2017, 20:27:11 (UTC-3), Tim Graham escribió:
>
> I'd suggest to use git bisect to find the Django commit where the behavior 
> changed:
>
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression
>
 

>
>
> On Wednesday, April 5, 2017 at 5:57:03 PM UTC-4, Maximiliano Robaina wrote:
>>
>> Hi,
>>
>>
>> I'm the maintener of django-firebird database backend.
>>
>> I've an strange behavior (a different result) when reading a value from a 
>> DecimalField between Django 1.7 and Django 1.8 and I'm trying to figured 
>> out where is my mistake.
>>
>> I've a django project which I update from 1.7 to 1.8.
>> In this project I've a model with a DecimalField.  (by example, price 
>> = DecimalField(max_digits=18, decimal_places=2)
>>
>> Then, in django 1.7
>>
>> >> obj = ModelWithDecimalField.objects.first()
>> >> obj.price
>> >>  Decimal("1990.00")
>>
>> In django 1.8
>>
>> >> obj = ModelWithDecimalField.objects.first()
>> >> obj.price
>> >>  Decimal("1990")
>>
>>
>> So, I don't know where look to found this change. What change between 1.7 
>> and 1.8
>> Maybe I forget to implement something in django-firebird 1.8
>>
>>
>> Thanks in advance
>> Maxi
>>
>>
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8dcbecbc-4edb-4eb8-b019-d659df7c7921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: can_introspect_default feature

[Maximiliano Robaina]

Hi,

Sorry but a need to return to this

El jueves, 20 de octubre de 2016, 9:53:23 (UTC-3), Tim Graham escribió:
>
> The 'default' model field option is used in Python rather than in the 
> database. SchemaEditor might set a column default to ease populating a 
> value on existing rows but that default shouldn't be left in the column's 
> definition. self.assertIsNone(field.default) means that the column 
> doesn't have a default.
>


Ok, you say that SchemaEditor set a column default to ease populating a 
value on existing row. Which sql engine works in that way?
I was reading into postgresql docs [1] and it says that add a column 
default definition "Note that this doesn't affect any existing rows in the 
table, it just changes the default for future INSERT commands.". So, I 
don't undertend why add a database default definition is useful if later we 
need to remove it.




 

>
>
> On Thursday, October 20, 2016 at 8:29:29 AM UTC-4, Maximiliano Robaina 
> wrote:
>>
>> Hi Tim,
>>
>> Thanks for response.
>>
>> El martes, 18 de octubre de 2016, 12:07:34 (UTC-3), Tim Graham escribió:
>>>
>>> Hi Maxi,
>>>
>>> Did you take a look at the relevant commit that introduced the flag?
>>>
>>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc
>>>
>>
>> Yes, I was looking into this changeset, but I can't understand yet what 
>> "And that the default is no longer set in the database." means in 
>> test_add_field_default_dropped [1].
>> field.default contains the column default definition not the default 
>> value of the some table record, Is it that correct?, So, why this must be 
>> None?
>>
>>
>>
>> [1] 
>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc#diff-888b45a0a8f38ee67e8d22403cf994dbR1371
>>
>>
>> Regards 
>>
>>
>>
>>>
>>> On Tuesday, October 18, 2016 at 9:51:46 AM UTC-4, Maximiliano Robaina 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> How supposed to can_introspect_default must work?
>>>>
>>>> I'm working on django firebird backend and I'm trying to figured out 
>>>> how this feature works, but the schema tests fails. 
>>>> This default is at database level or django level?
>>>>
>>>> If I define a field with a default value, and do a metadata 
>>>> introspection over this field to know if default value is defined, it 
>>>> always returns True.
>>>>
>>>> I hope be clear (sorry for my bad english)
>>>>
>>>> ---
>>>> Maxi
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df9f8a7d-eba6-4108-9506-a3a69e2edc0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: can_introspect_default feature

[Maximiliano Robaina]

Hi Shai,


El martes, 25 de abril de 2017, 18:28:57 (UTC-3), Shai Berger escribió:
>
> Hi Maxi, 
>
> On Tuesday 25 April 2017 20:21:47 Maximiliano Robaina wrote: 
> > Hi, 
> > 
> > Sorry but a need to return to this 
> > 
> > El jueves, 20 de octubre de 2016, 9:53:23 (UTC-3), Tim Graham escribió: 
> > > The 'default' model field option is used in Python rather than in the 
> > > database. SchemaEditor might set a column default to ease populating a 
> > > value on existing rows but that default shouldn't be left in the 
> column's 
> > > definition. self.assertIsNone(field.default) means that the column 
> > > doesn't have a default. 
> > 
> > Ok, you say that SchemaEditor set a column default to ease populating a 
> > value on existing row. Which sql engine works in that way? 
>
> All of them, as far as I know. 
>
> > I was reading into postgresql docs [1] and it says that add a column 
> > default definition "Note that this doesn't affect any existing rows in 
> the 
> > table, it just changes the default for future INSERT commands.". So, I 
> > don't undertend why add a database default definition is useful if later 
> we 
> > need to remove it. 
> > 
>
> That statement is correct if it refers to adding a default definition to 
> an 
> existing column, but SchemaEditor uses defaults only when it adds new 
> columns. 
> if you add a new column to a table that already has rows, then the easiest 
> way 
> to set a value for all existing rows is to define it as default. If the 
> column 
> is not nullable, you actually cannot add it without a default. 
>
> And yet, some Python defaults cannot be represented in SQL (mostly 
> functions), 
> and we'd much rather use Python defaults. Experience (in South) has shown 
> that 
> defaults in the database, when used carelessly, cause problems, so we try 
> to 
> keep them out. 
>

Yes, I understand that and I agree. I my case, Firebird has an strange 
behavior when you add a new not null field with a default  and then remove 
the default definition.
I must to implement other strategies.

Regards
Maxi


 

>
> HTH, 
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c7f2d7d3-a540-486e-9e61-cf89e3911abf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.