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 wrote:
> Hi,
>
> I'm working on django-firebird project and doing some modifications
> for work with django 1.2
>
ll 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,
odels 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
--~--~-~--~~~
Today i was looking at this. I'll just drop my attempt at the
definition API:
class Entity:
account = models.CharField()
number = models.IntegerField()
class Meta:
primary_key=('account', 'number')
class Invoice:
number = models.IntegerField()
group = models.CharFiel
On Sep 6, 8:06 pm, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
> Am I on the right track? Do you people have other ideas?
>
Some backends provide some type_cast functions that you can attach to
some data types, on a quick search for zxJDBC I found in the home page
"Datatype mapping callbacks through
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
Russell Keith-Magee escreveu:
> On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm afraid I don't see the benefit of what you are proposing. The
> serialization framework exists for the easy serialization of Django
> DB-backed objects - not for the arbitrary serialization of _any_
> ob
ield'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"
efactoring 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
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.
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.
I was able to reproduce this error by enable the admin in the
INSTALLED_APPS and in urls.py but not sync'ed to database, make sure
you call manage.py syncdb to install also the admin app.
Fabio Gomes escreveu:
Thanx, it worked now.
I was able to create the table, acess the objects, add, update
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 PROTECT
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-
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
>
[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
aproa
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(
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 Goo
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
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
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 thi
Hi there,
I've started working on firebird's backend and Adrian is also
refactoring for the oracle support, so it's a good time to discuss this
:)
First, field and constraint names can't be bigger than 31 chars.
In the creation.py declared for PositiveIntegerField
integer CHECK("%(column)s"
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 so
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.
Although i don't get it ye
uld 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
>
Hi there,
Is anyone working on this?
I already found some problems for the firebird adapter, or not :)
For example the LIMIT OFFSET clause, firebird uses SELECT FIRST SKIP
and the sql construction in django implies that the limit offset is
always appended with the backed.get_limit_offset_sql()
26 matches
Mail list logo
