Re: working django with existing database

errr...what do you think

i read at http://code.activestate.com/recipes/285262-create-objects-from-variable-class-names/

class Bunch(dict):
    def __init__(self,**kw):
            dict.__init__(self,kw)
            self.__dict__ = self

fruit = Bunch(apples=1, pears=2)
print fruit.apples
print fruit.pears

why doesn't we could use something like this to store data output from database to object??

2011/1/31 Adrian Bool <aid@logic.org.uk>

Arief,

Just do a search and replace in your text file along the lines of,

search for,

max_digits=0, decimal_places=-127

replace,

max_digits=10, decimal_places=2

And Django should be happy.

aid

On 31 Jan 2011, at 10:29, arief nur andono wrote:

oh please...

i need only to query the table, have no access to modified the table

why there is no way query the database and then make the output as object??

2011/1/31 Ian <ian.g.kelly@gmail.com>

On Jan 31, 12:20 am, arief nur andono <ariefnurand...@gmail.com>
wrote:

> class TempJmlGangguanPyl(models.Model):
>     singkatpyl = models.CharField(max_length=4, blank=True)
>     singkatgrd = models.CharField(max_length=4, blank=True)
>     jumlah_gangguan = models.DecimalField(null=True, max_digits=0,
> decimal_places=-127, blank=True)
>     lama_gangguan = models.DecimalField(null=True, max_digits=0,
> decimal_places=-127, blank=True)
>     class Meta:
>         db_table = u'temp_jml_gangguan_pyl'

It appears that your numeric columns are all decimal-precision
floating-point (i.e. "FLOAT" or "NUMBER" with no precision or scale
specified), which is a bit of a corner case.  The basic problem is
that Django core has no field for this.  DecimalField can only handle
fixed-point, and FloatField uses binary precision.  If these columns
are actually used to store fixed-point data, you could manually update
the generated models (or preferably the original schema) with the
actual precision and scale of the data.  If they are truly floating-
point, then you would probably need to write a custom DecimalField
class.  I wouldn't recommend changing them to FloatField in any case,
because that could result in a loss of precision.

A similar problem can be encountered with "NUMBER(p, s)" columns where
s < 0 or s > p.  Both these scenarios are perfectly valid in Oracle,
but are (somewhat arbitrarily) disallowed by the DecimalField
validation.

I'll make a note of this.  At the very least, there should be a more
descriptive error message for when this comes up.

Ian

--

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

--

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

Adrian Bool

aid@logic.org.uk

--

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

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