Re: firebird backend for django
Hi,
I've opened a ticket for months ago -
http://code.djangoproject.com/ticket/13159.
Only needs a test case.
David Elias
On Jul 23, 10:30 pm, maxi <maxiroba...@gmail.com> 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 at
http://groups.google.com/group/django-developers?hl=en.
Re: Models split and Model._meta.installed
On Nov 30, 12:31 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Both of these changes look like they should work for your particular > situation. They aren't a general solution to the problem -- although > generalising to work correctly might not be too hard -- since you've > changed the hard-coded assumption from zero levels of nesting to only > one level of nesting. Which means that two levels of nesting will still > break, etc. Actually i've coded the change with infinite nesting levels in mind and tested too, again it's working, after all django always assume "models" module must be contained by our app module. regards, David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Models split and Model._meta.installed
In my projects i often split models into several files inside a models
folder:
some_app /
models /
__init__.py
some_models.py
other_models.py
...
I know i must set app_label in Meta options, but even so
Model._meta.installed returns false. In
django.db.models.options.Options i've changed:
self.installed = re.sub('\.models$', '', cls.__module__) in
settings.INSTALLED_APPS
to this:
self.installed = re.sub('\.models.*', '', cls.__module__) in
settings.INSTALLED_APPS
capturing all from 'models'.
Is this ok or it will break anything? At least for me is working.
Another thing is that we must set the app_label, i've made another
change, in django.db.models.base.ModelBase we have:
kwargs = {"app_label": model_module.__name__.split('.')[-2]}
In the above models layout the app_label would be "models", now is set
to "some_app" with this change:
parts = model_module.__name__.split('.')
kwargs = {"app_label": parts[parts.index('models')-1]}
regards,
David Elias
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Serialize model properties enhancement
On Apr 28, 2:48 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > The open question in my mind is where the serialized data goes - do we > put it into the fields block, or do we start a new 'extra' block? i.e, > which of the following JSON outputs would you expect? I prefer the latter too, with the extra block. > And what happens on deserialization? Is the attribute restored, or > ignored? I'm inclined to prefer the latter serialization format, and > ignore on restoration, but I'd be interested in hearing other > opinions. Regarding deserialization, i guess if a queryset will set these extra columns to a model why not restore them? David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Firebird backend against 0.96 release and thoughts
Malcolm Tredinnick escreveu: > We could arrange for this to be possible as part of the QuerySet > refactor. I hadn't thought of doing it before, but it's not a bad idea. > Might even help things like the GIS branch, too. > > /me makes a TODO note. That would be perfect. I imagine that you will come with a similar aproach like sqlalchemy and the multi-db branch(i guess) that each backend can overwrite the needed bits. If i'm wrong ignore my comment... :) > Since 2.1 is still a pre-release, isnt' that going to seem a bit harsh > on the user base. It's not really going to be a backend that existing > Firebird users can use if that were the minimum. > > I realise that last sentence doesn't help at all with solving your > problem. Merely pointing out the PR problem this presents. Yes you're right. The iendswith on TextField's will be impossible, maybe with some UDF. IMO if it will be in trunk it should when firebird 2.1 is released. David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Firebird backend against 0.96 release and thoughts
The new patch - http://code.djangoproject.com/ticket/1261 Like I've explained in the ticket's comments right now we can't do a search in TextFields with: __istartswith, __iendswith, __icontains These work well with VARCHAR using LIKE and the UPPER function just like the oracle branch, but only in Firebird 2.1 it's possible to treat a BLOB with 32k limit size like a VARCHAR. For __icontains firebird has CONTAINING but that does not use index. Some special case could be used if we knew the field type in "query.get_where_clause" function, maybe with the refactoring it will be possible. __istartswith could be possible using STARTING, it uses index for VARCHARS and works with BLOBS. __iendswith is not possible (i could be wrong). What you, django devs, think? If this backend would be added to trunk should firebird 2.1 be the minimal version? David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Firebird backend improved
I've uploaded a new patch against the oracle branch and updated the backend module. You can check http://code.djangoproject.com/ticket/1261 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New firebird backend using the boulder-oracle-sprint branch
Is there anything i can help with? I m don´t have much python knowledge Same with me :) but i m really interested in firebird support in django, so if i can help testing or doing something it will be a pleasure. Well you can use this patch on your projects and report bugs and enhancements. also, is there any plans to add it in the main django release in the future? Well it all depends, for now, the oracle branch. I was also trying to build the Django ORM around SQLAlchemy sql package, not the ORM package, but that's another story. Again, thanx a lot for doing this great job :) Sempre às ordens! ^^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New firebird backend using the boulder-oracle-sprint branch
Make sure you are using the boulder-oracle-sprint branch and your PYTHONPATH is pointing to that. Fabio Gomes wrote: > I tried it and i m getting this error: > > > File "/usr/lib/python2.4/site-packages/django/db/backends/firebird/base.py", > line 100, in quote_name > name = '"%s"' % util.truncate_name(name.upper(), get_max_name_length()) > AttributeError: 'module' object has no attribute 'truncate_name' > > Any ideas? > > On 12/18/06, Fabio Gomes <[EMAIL PROTECTED]> wrote: > > Thanx man, i ll test it right away. > > > > I was trying to hack your old one, but i didnt figure out why some > > generators weren´t created, so i was having some problems. > > > > -- Forwarded message -- > > From: David Elias <[EMAIL PROTECTED]> > > Date: Dec 18, 2006 1:14 PM > > Subject: New firebird backend using the boulder-oracle-sprint branch > > To: Django developers <django-developers@googlegroups.com> > > > > > > > > Please check http://code.djangoproject.com/ticket/1261 > > > > David Elias > > > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
New firebird backend using the boulder-oracle-sprint branch
Please check http://code.djangoproject.com/ticket/1261 David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
Robin Munn wrote: > The notes on implementation that Adrian posted pretty much match what > I'm thinking at this point. The plan is to make this 100% API > compatible (if possible -- you never know what will turn up once you > start implementing some idea), so that existing code doesn't need to > change. But if you want access to the underlying SQLAlchemy objects to > do something like a nine-table query involving five LEFT OUTER JOINs > and two subselects, well, you should be able to do that as well. Indeed great news!! At work i am trying to build the Django ORM on the top of SQLAlchemy core. I've tried on the top of the ORM but it was overkill, but i could had done something wrong. I was getting about ~10 request per second oposed to ~50 request per second with firebird. Are you planning to build the integration on the top of the SQLAlchemy ORM? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multiple database support (#1142) roadblock
[EMAIL PROTECTED] wrote: > perhaps we could put it all into backend/creation.py. That's what i had, early, implemented with the firebird backend patch, put the sequence and triggers sql in creation.py. And now i was trying retain the management.py intact in terms of functionality, but your aproach in puting all the sql statements in creation module is better, i think. At least will give much more flexibility for generating SQL for all backends. Nice work. David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Already added the patch, for the ones that didn't know - http://code.djangoproject.com/ticket/1261 I'm trying to remove the "if settings.DATABASE_ENGINE == 'firebird'" from management.py and add some signals to use with the dispatcher. Already got this working inside the function "get_sql_create(app)" sending post_sql_create signal and connecting to this signal in the creation module, modifying the final_ouput. Adrian, assuming that you are working on database support, are any plans that each backend may add sql statements to the sqlall output in the future? ps: sorry for my english David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
I've got the backend's base, create and introspection almost done. Should i create a ticket or use this one http://code.djangoproject.com/ticket/1261 and attach the files? David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Adrian Holovaty wrote:
> On 6/1/06, David Elias <[EMAIL PROTECTED]> wrote:
> >
> > Well, AS in FROM clause is not support...
> >
> > Thoughts, ideas...?
>
> Hey David,
>
> Sorry for the slow response -- let's take each issue one at a time.
> What do you have coded so far?
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
Hi,
I have made some nasty changes in management.py for quick testing,
removed "referencing" when creating contraints, but that will not
resolve the column name size limit. Changed NULL to DEFAULT NULL.
Firebird suffers from the same problem as Mysql concerning date/time
fields, it doens't accept the microseconds, so i've changed in
fields/__init__.py
I've also changed models/base.py in save method:
backend.add_limit_offset_sql("SELECT 1 FROM %s WHERE %s=%%s", 1)
So far sessions are working :)
David
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Michael Radziej wrote: > David Elias wrote: > > Well, AS in FROM clause is not support... > > Not even in the equivalent form > > SELECT ... FROM table_name alias > > ? > > That would really suck. How do you do joins to "self" then? > > Michael With all the work i've forgot that, made a simple test and worked, thanks! Already have admin app working, i'm going to test removing AS. David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Well, AS in FROM clause is not support... Thoughts, ideas...? I think we're not going to have Firebird support in Django :p --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Some thoughts about the new settings.configure() and decoupling
Malcolm Tredinnick wrote: > Hi David, > > On Mon, 2006-05-22 at 15:06 -0700, David Elias wrote: > > I think one way to go is with factories. > > The packages don't know nothing where settings coming from. These > > settings are passed within a constructor or something and django would > > use factories that know to look from django.conf.settings and passed > > them to the new object. > > That is precisely how it is currently implemented, in effect. Although > it's not a completely plain "factory function", when you first access > django.conf.settings or call configure(), it sets up the right > settings-producing class that is used on all subsequent uses of > django.conf.settings. It's not what a Computer Science student might > immediately identify as a factory function from the shape of the code, > but it is doing the same thing. > > And if, for some reason, you wanted to override the settings "producer", > dropping a new implementation of UserSettingsHolder into django.conf is > not too hard either (not documented, since there should be almost no > reason for it and it's not that hard to read the code if you need to). > Something like > > from django import conf > > conf.UserSettingsHolder = MyUserSettingsHolder > conf.settings.configure(...) > > will work if you do it before anything else accesses the settings. > > > > Although i don't get it yet, i think dependency injection > > (http://www.martinfowler.com/articles/injection.html) could be a > > possible solution :-) > > I'm not entirely sure what you are suggesting here. How does this help > with the usage of this feature (which I assume is what you're talking > about)? At some point, you still have to tell Django what the values for > your particular set of configuration variables are. Or use the defaults. > The configure() function provides that functionality at the moment. > > I'm really not sure what pieces you are trying to "decouple" here. > Things like the templating system and ORM need configuration settings. > Some some infrastructure is required. Omitting anything from under > django.conf entirely would not really save lines of code overall. And > the usage API seems about as minimal as you can get (set what you need, > use default for the rest). So can you explain you thinking further? Hi there, I was thinking in way to remove lines like this from django.conf import settings from the template system and ORM, something like passing the desireable settings within the constructor, or something. About the factories i was not mention the one of django.conf, i was thinking in factories that belongs to django and not to the template system or ORM. Right now i don't have some code to demonstrate, i'm also writing a firebird backend so i'm learning how the frameworks works as well. > > Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Firebird support
> Hi David, Hi, thanks for the response. > I don't know of any work being done on a Firebird adapter. Would you > like to volunteer? :) Shure :) at work we are building a portal that will work as bridge between the our software (similar to SAP) and it uses Firebird, so it's a must we use it as the portal backend's database and since we are already building 4 sites with Django... > As for the get_limit_offset_sql() thing, I don't see any huge problems > with us refactoring that to be more like add_limit_offset(sql). That's great, oracle adapter would benefit from this as well. The ideal would be the backend's adaptor handle the SQL construction much as possible instead of the query module. > (If you do decide to work on it, make sure > to do it on Django's trunk, formerly magic-removal, rather than on > 0.91-style code.) Already working with it :) David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
