Re: New design for class-based views

[akaariai]

On Dec 3, 8:56 pm, Tobia Conforto  wrote:
> I haven't taken the time to translate the whole django.views.generic
> package to this new design, but I will do so shortly, assuming I get
> some kind of positive feedback. The existing functionality (the
> various generic views and mixins) should be fairly easy to port to the
> new design.

It is very important to make sure that you can support all the
features supported by Django currently. The devil is in the details.
Trying to pass Django's test suite with your version of class based
views is a good way to test if you actually do achieve feature parity.

I don't know much about class based views, but I do know that their
design thread at django-developers was _very_ long. So, there might be
reason why things are done as they are.

> This is a slightly different design, so there are bound to be a few
> incompatibilities. For example in my code the dispatched methods (get,
> post...) don't receive the request object and parameters, because they
> were already passed to __init__ and it wouldn't make sense to pass
> them again.
>
> I'm not familiar with Django practices about backwards compatibility.
> If it's really important not to break old code, I guess the new style
> classes could be made to keep the same interface as existing ones,
> including a dummy as_view() method. But it would pollute the code with
> old cruft. Or they could be implemented in a new package. I need
> further directions on this issue.

Django has a strict backwards compatibility policy. If the users have
used public APIs, their code must work in the next release (barring
data-corruption / security issues). Deprecation takes two releases.
This means that you must provide backwards compatibility wrappers /
methods.

 - Anssi

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

Re: Bulk import of data

[Karen Tracey]

On Sat, Dec 3, 2011 at 9:37 PM, Nathan McCorkle  wrote:

> when you say 'as long as you don't use the ORM for inserts',


You do not want to be building and saving objects individually with the
ORM. You want to be using some form of bulk insert. Django 1.4 will add
bulk create capability (see
https://docs.djangoproject.com/en/dev/ref/models/querysets/#bulk-create).
Prior to 1.4 you can use the development trunk level code, or you can find
other libraries that provide bulk insert (see for example
http://ole-laursen.blogspot.com/2010/11/bulk-inserting-django-objects.html).
http://www.caktusgroup.com/blog/2011/09/20/bulk-inserts-django/ mentions
the kinds of speedups you can expect with using a bulk insert technique vs.
creating objects individually with the ORM.

Karen
-- 
http://tracey.org/kmt/

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

Re: Bulk import of data

[Nathan McCorkle]

On Fri, Dec 2, 2011 at 6:22 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Faster in what sense? Prototyping/development time, or run time?

Well I can count the lines in each file in a few seconds, so I think
the SQL stuff is slowing everything down (using postgres through
psycodb2)

>
> If it's only a few MB, I see little reason to go as far as to writing it in
> C. Unless you are performing the same import tens of thousands of times, and
> the overhead in Python adds up so much that you get problems.
>
> But, quite frankly, you'll max out MySQL INSERT performance before you max
> out Pythons performance lol - as long as you don't use the ORM for inserts
> :)

when you say 'as long as you don't use the ORM for inserts', do you
mean don't do:
currentDataset.comment="blah"
currentDataset.name="abc12"
currentDataset.relatedObject=otherCurrentObject.id

etc,etc?

Are you saying I should be doing all that in python, but using raw SQL
instead of the fancy python object-like way? like this:
https://docs.djangoproject.com/en/dev/topics/db/sql/#executing-custom-sql-directly

>
> Cal
>
>
> On Fri, Dec 2, 2011 at 5:21 AM, Nathan McCorkle  wrote:
>>
>> would interfacing with SQL via C or C++ be faster to parse and load
>> data in bulk? I have files that are only a few MB worth of text, but
>> can take hours to load due to the amount of parsing I do, and the
>> number of database entries each item in a file makes
>>
>> On Mon, Nov 28, 2011 at 3:28 AM, Anler Hernandez Peral
>>  wrote:
>> > Hi, this is probably not your case, but in case it is, here is my story:
>> > Creating a script for import CSV files is the best solution as long as
>> > they
>> > are few, but in my case, the problem was that I need to import nearly 40
>> > VERY BIG CSV files, each one mapping a database table, and I needed to
>> > do it
>> > quickly. I thought that the best way was to use MySQL's "load data in
>> > local..." functionality since it works very fast and I could create only
>> > one
>> > function to import all the files. The problem was that my CSV files were
>> > pretty big and my database server were eating big amounts of memory and
>> > crashing my site so I ended up slicing each file in smaller chunks.
>> > Again, this is a very specific need, but in case you find yourself in
>> > such
>> > situation, here's my base code from which you can extend ;)
>> >
>> > https://gist.github.com/1dc28cd496d52ad67b29
>> > --
>> > anler
>> >
>> >
>> > On Sun, Nov 27, 2011 at 7:56 PM, Andre Terra 
>> > wrote:
>> >>
>> >> This should be run asynchronously (i.e. celery) when importing large
>> >> files.
>> >> If you have a lot of categories/subcategories, you will need to bulk
>> >> insert them instead of looping through the data and just using
>> >> get_or_create. A single, long transaction will definitely bring great
>> >> improvements to speed.
>> >> One tool is DSE, which I've mentioned before.
>> >> Good luck!
>> >>
>> >> Cheers,
>> >> AT
>> >>
>> >> On Sat, Nov 26, 2011 at 8:44 PM, Petr Přikryl  wrote:
>> >>>
>> >>> >>> import csv
>> >>> >>> data = csv.reader(open('/path/to/csv', 'r'), delimiter=';')
>> >>> >>> for row in data:
>> >>> >>> category = Category.objects.get_or_create(name=row[0])
>> >>> >>> sub_category = SubCategory.objects.get_or_create(name=row[1],
>> >>> >>> defaults={'parent_category': category})
>> >>> >>> product = Product.objects.get_or_create(name=row[2],
>> >>> >>> defaults={'sub_category': sub_category})
>> >>>
>> >>> There are few potential problems with the cvs as used here.
>> >>>
>> >>> Firstly, the file should be opened in binary mode.  In Unix-based
>> >>> systems, the binary mode is technically similar to text mode.
>> >>> However, you may once observe problems when you move
>> >>> the code to another environment (Windows).
>> >>>
>> >>> Secondly, the opened file should always be closed -- especially
>> >>> when building application (web) that may run for a long time.
>> >>> You can do it like this:
>> >>>
>> >>> ...
>> >>> f = open('/path/to/csv', 'rb')
>> >>> data = csv.reader(f, delimiter=';')
>> >>> for ...
>> >>> ...
>> >>> f.close()
>> >>>
>> >>> Or you can use the new Python construct "with".
>> >>>
>> >>> P.
>> >>>
>> >>> --
>> >>> 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+unsubscr...@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
>> >> 

Re: Pointing to Memcached on Remote Server

[huseyin yilmaz]

Also check memcached configuration (/etc/memcached.conf)
from this file,you can limit IP addresses that memcached listening to
here is a configuration parameter that you might have

# Specify which IP address to listen on. The default is to listen on
all IP
addresses
# This parameter is one of the only security measures that memcached
has, so make
sure
# it's listening on a firewalled
interface.
#-l 127.0.0.1


On Dec 2, 3:49 am, mattym  wrote:
> Hi all -
>
> I am stuck on this one. Caching with memcached works when I reference
> the local box holding Django. But when I point my setting to a remote
> box it does not cache:
>
> This is with Django 1.3 using python-memcached on the localbox in a
> virtualenv
>
>  'default': {
>         'BACKEND':
> 'django.core.cache.backends.memcached.MemcachedCache',
>         #'LOCATION': ['127.0.0.1:11211',]  # This works
>         'LOCATION': ['xx.xxx.xxx.xx:11211',]  # This remote one does not
>     }
>
> My settings file appears to have the proper middleware installed:
>
>  "django.middleware.gzip.GZipMiddleware",
>   "django.middleware.cache.UpdateCacheMiddleware",
>     "django.contrib.sessions.middleware.SessionMiddleware",
>     "django.contrib.auth.middleware.AuthenticationMiddleware",
>     "django.contrib.redirects.middleware.RedirectFallbackMiddleware",
>     "mezzanine.core.middleware.DeviceAwareUpdateCacheMiddleware",
>     "django.middleware.common.CommonMiddleware",
>     "django.middleware.csrf.CsrfViewMiddleware",
>     "mezzanine.core.middleware.DeviceAwareFetchFromCacheMiddleware",
>     "mezzanine.core.middleware.AdminLoginInterfaceSelector",
>     "django.middleware.cache.FetchFromCacheMiddleware",
>
> I've checked that memcached is running on the remote box. I am
> probably overlooking something simple.
> Any help is greatly appreciated.
>
> Thanks,
> Matt

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

Re: Console output using runserver..

[vivek_12315]

I just figured out that

if I use :
http://127.0.0.1:8081/ner/
then I am getting print output in console,

but if I use:
 http://localhost:8081/ner/

then i am not getting the output  Whats the reason behind this /
??

On Dec 3, 12:34 pm, vivek_12315  wrote:
> This is what Django webpage is showing as error:
>
> 
> OperationalError at /ner/
>
> no such table: b_mp_TABLE
>
> Request Method:         POST
> Request URL:    http://localhost/ner/
> Exception Type:         OperationalError
> Exception Value:
>
> no such table: b_mp_TABLE
>
> Exception Location:     C:/lilly-search/pySolr\webinterface\api\ner.py in
> get_more_words_per_entity, line 75
> Python Executable:      C:\Program Files\Apache Software Foundation
> \Apache2.2\bin\httpd.exe
> Python Version:         2.5.4
> Python Path:    ['C:\\Python25\\Lib\\site-packages\\setuptools-0.6c11-
> py2.5.egg', 'C:\\Python25\\Lib\\site-packages\\sparqlwrapper-1.4.2-
> py2.5.egg', 'C:\\Python25\\Lib\\site-packages\\simplejson-2.0.9-py2.5-
> win32.egg', 'C:\\Python25\\Lib\\site-packages\\rdflib-3.1.0-
> py2.5.egg', 'C:\\Python25\\Lib\\site-packages\\django', 'C:\\Python25\
> \Lib\\site-packages', 'C:\\Program Files\\Apache Software Foundation\
> \Apache2.2', 'C:\\WINDOWS\\system32\\python25.zip', 'C:\\Python25\
> \Lib', 'C:\\Python25\\DLLs', 'C:\\Python25\\Lib\\lib-tk', 'C:\\Program
> Files\\Apache Software Foundation\\Apache2.2\\bin', 'C:\\Python25',
> 'C:/lilly-search/pySolr', 'C:/Django-1.0.2-final']
> Server time:    Sat, 3 Dec 2011 15:39:48 -0800
>
> 
>
> Is something wrong with apache ? Is apache not allowed to read the db
> file which I have ?

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

Re: Is it possible to use MS SQL 2008 as the Django database engine?

[David Fischer]

It is possible. The two major projects that I know of are 
django-pyodbcwhich I have used quite a 
bit and 
django-mssql  which I have not 
used. 

Django-mssql only works on Windows and I have no experience with it. As far 
as I know, it uses the Microsoft drivers underneath so it probably works 
fairly well.

Django-pyodbc works on Linux or Windows but if you were building for 
Windows, you would probably just use django-mssql. On Linux, you will need 
either unixODBC or iODBC as well as FreeTDS. On Ubuntu or CentOS, these are 
available from the package manager. Getting everything working is not 
entirely trivial due to different authentication schemes with SQL Server 
and some other intricacies. The code is not as seamless as the Django 
supported backends and deciding to use django-pyodbc will probably mean 
you'll have to learn the code line and submit a few patches. I use it 
primarily to connect to a read-only legacy database and for that purpose it 
works well. 

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

Re: Console output using runserver..

[vivek_12315]

This is what Django webpage is showing as error:


OperationalError at /ner/

no such table: b_mp_TABLE

Request Method: POST
Request URL:http://localhost/ner/
Exception Type: OperationalError
Exception Value:

no such table: b_mp_TABLE

Exception Location: C:/lilly-search/pySolr\webinterface\api\ner.py in
get_more_words_per_entity, line 75
Python Executable:  C:\Program Files\Apache Software Foundation
\Apache2.2\bin\httpd.exe
Python Version: 2.5.4
Python Path:['C:\\Python25\\Lib\\site-packages\\setuptools-0.6c11-
py2.5.egg', 'C:\\Python25\\Lib\\site-packages\\sparqlwrapper-1.4.2-
py2.5.egg', 'C:\\Python25\\Lib\\site-packages\\simplejson-2.0.9-py2.5-
win32.egg', 'C:\\Python25\\Lib\\site-packages\\rdflib-3.1.0-
py2.5.egg', 'C:\\Python25\\Lib\\site-packages\\django', 'C:\\Python25\
\Lib\\site-packages', 'C:\\Program Files\\Apache Software Foundation\
\Apache2.2', 'C:\\WINDOWS\\system32\\python25.zip', 'C:\\Python25\
\Lib', 'C:\\Python25\\DLLs', 'C:\\Python25\\Lib\\lib-tk', 'C:\\Program
Files\\Apache Software Foundation\\Apache2.2\\bin', 'C:\\Python25',
'C:/lilly-search/pySolr', 'C:/Django-1.0.2-final']
Server time:Sat, 3 Dec 2011 15:39:48 -0800



Is something wrong with apache ? Is apache not allowed to read the db
file which I have ?

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

New design for class-based views

[Tobia Conforto]

Hello

As you may know, current class-based views have been criticized for
their complexity.

Their design is a bit convoluted and difficult to understand by the
average view author and therefore any work made with them may hide
sneaky bugs.

On top of that, it's difficult to apply common decorators to them. The
recommended approach seems to be to apply them to the dispatch()
method. But this requires overriding that method even when the base
dispatch strategy is otherwise adequate, and converting the decorators
with method_decorator(). This is ugly and is only a partial solution,
as method_decorator() doesn't currently support decorators with
arguments, such as @user_passes_test(a_test).

All this is unfortunate, because there is a clear need for a simple,
Pythonic object-oriented approach to view authoring, to achieve
separation of concerns and code reuse. Dispatching by http method (one
of the basic features of class-based views) is also a growing need, in
the world of AJAX and REST-based web applications.

I have attached my proposal for a slight change in the design of class-
based views. It is similar in purpose to the existing ones, but much
simpler to use and to extend.

Examples speak louder than words:

--- urls.py ---

urlpatterns = patterns('',
url(r'^(\d)+/$', views.Article),
)

--- views.py ---

@login_required
class Article(View):

def __init__(self, request, pk):
super(Article, self).__init__(request, pk)
self.pk = pk

def get(self):
article = get_object_or_404(Article, pk=self.pk)
return render_to_response('hello.html', {'article': article})

def post(self):
return HttpResponse('You posted something but I threw it
away.')

---

Points of note:
 - the usage in urls.py is now indistinguishable from regular views;
 - subclasses may extend __init__ to make use of request parameters;
 - the dispatch logic, based on http method, is hidden in the base
class;
 - standard decorators may be simply applied to the class (Python >=
2.6)

Here is the View base class: http://dpaste.com/hold/665528/
It's very simple, even shorter than the existing implementation.

I haven't taken the time to translate the whole django.views.generic
package to this new design, but I will do so shortly, assuming I get
some kind of positive feedback. The existing functionality (the
various generic views and mixins) should be fairly easy to port to the
new design.

This is a slightly different design, so there are bound to be a few
incompatibilities. For example in my code the dispatched methods (get,
post...) don't receive the request object and parameters, because they
were already passed to __init__ and it wouldn't make sense to pass
them again.

I'm not familiar with Django practices about backwards compatibility.
If it's really important not to break old code, I guess the new style
classes could be made to keep the same interface as existing ones,
including a dummy as_view() method. But it would pollute the code with
old cruft. Or they could be implemented in a new package. I need
further directions on this issue.

-Tobia

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

Re: Error in syncdb

[Jeff Heard]

Never mind.  My error was elsewhere.  A little putzing around led me to
realize that you can't put db_index=True into a geometry field of any sort
in PostGIS backend.

On Sat, Dec 3, 2011 at 11:25 AM, Jeff Heard wrote:

> I have a custom field type that I defined, and now I can't do a syncdb.
>  The relevant bits of the type are
>
> class PyMongoField(models.CharField):
>__metaclass__ = models.SubFieldBase
>
>...
>def db_type(self, connection):
>   return 'varchar(64)'
>...
>
> But I just get this when I do reset or syncdb on an app with a model that
> uses that field type.  Any clue?
>
> Traceback (most recent call last):
>   File "manage.py", line 14, in 
> execute_manager(settings)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/__init__.py",
> line 438, in execute_manager
> utility.execute()
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/__init__.py",
> line 379, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/base.py",
> line 191, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/base.py",
> line 220, in execute
> output = self.handle(*args, **options)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/base.py",
> line 286, in handle
> app_output = self.handle_app(app, **options)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/commands/reset.py",
> line 35, in handle_app
> sql_list = sql_reset(app, self.style, connection)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/sql.py",
> line 107, in sql_reset
> return sql_delete(app, style, connection) + sql_all(app, style,
> connection)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/sql.py",
> line 146, in sql_all
> return sql_create(app, style, connection) + sql_custom(app, style,
> connection) + sql_indexes(app, style, connection)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/sql.py",
> line 141, in sql_indexes
> output.extend(connection.creation.sql_indexes_for_model(model, style))
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/db/backends/creation.py",
> line 250, in sql_indexes_for_model
> output.extend(self.sql_indexes_for_field(model, f, style))
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/contrib/gis/db/backends/postgis/creation.py",
> line 12, in sql_indexes_for_field
> output = super(PostGISCreation, self).sql_indexes_for_field(model, f,
> style)
>   File
> "/opt/data/ga/jeff/lib/python2.7/site-packages/django/db/backends/postgresql/creation.py",
> line 68, in sql_indexes_for_field
> if db_type.startswith('varchar'):
> AttributeError: 'NoneType' object has no attribute 'startswith'
>
>

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

Error in syncdb

[Jeff Heard]

I have a custom field type that I defined, and now I can't do a syncdb.
 The relevant bits of the type are

class PyMongoField(models.CharField):
   __metaclass__ = models.SubFieldBase

   ...
   def db_type(self, connection):
  return 'varchar(64)'
   ...

But I just get this when I do reset or syncdb on an app with a model that
uses that field type.  Any clue?

Traceback (most recent call last):
  File "manage.py", line 14, in 
execute_manager(settings)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/__init__.py",
line 438, in execute_manager
utility.execute()
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/__init__.py",
line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/base.py",
line 191, in run_from_argv
self.execute(*args, **options.__dict__)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/base.py",
line 220, in execute
output = self.handle(*args, **options)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/base.py",
line 286, in handle
app_output = self.handle_app(app, **options)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/commands/reset.py",
line 35, in handle_app
sql_list = sql_reset(app, self.style, connection)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/sql.py",
line 107, in sql_reset
return sql_delete(app, style, connection) + sql_all(app, style,
connection)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/sql.py",
line 146, in sql_all
return sql_create(app, style, connection) + sql_custom(app, style,
connection) + sql_indexes(app, style, connection)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/core/management/sql.py",
line 141, in sql_indexes
output.extend(connection.creation.sql_indexes_for_model(model, style))
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/db/backends/creation.py",
line 250, in sql_indexes_for_model
output.extend(self.sql_indexes_for_field(model, f, style))
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/contrib/gis/db/backends/postgis/creation.py",
line 12, in sql_indexes_for_field
output = super(PostGISCreation, self).sql_indexes_for_field(model, f,
style)
  File
"/opt/data/ga/jeff/lib/python2.7/site-packages/django/db/backends/postgresql/creation.py",
line 68, in sql_indexes_for_field
if db_type.startswith('varchar'):
AttributeError: 'NoneType' object has no attribute 'startswith'

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

Is it possible to use MS SQL 2008 as the Django database engine?

[Petr Přikryl]

Hi, 

Do you have any experience with using Microsort SQL Server 2008 as the Django 
database engine?  I understand that it is not supported directly.  However, is 
it possible to add some kind of module that implements the Django database 
interface for the MS SQL?

Thanks for your time and experience,
Petr

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

Multiple access to static data

[mf]

I'm building an application and I'm having trouble making a choice
about how is the best way to access multiple times to static data in a
django app. My experience in the field is close to zero so I could use
some help.

The app basically consists in a drag & drop of foods. When you drag a
food to a determined place(breakfast for example) differents values
gets updated: total breakfast calories, total day nutrients(Micro/
Macro), total day calories, ...That's why I think the way I store and
access the data it's pretty important performance speaking.

This is an excerpt of the json file I'm currently using:

foods.json

{
"112": {
"type": "Vegetables",
"description": "Mushrooms",
"nutrients": {
"Niacin": {
"unit": "mg",
"group": "Vitamins",
"value": 3.79
},
"Lysine": {
"units": "g",
"group": "Amino Acids",
"value": 0.123
},
... (+40 nutrients)
"amount": 1,
"unit": "cup whole",
"grams": 87.0 }
 }

I've thought about different options:

1) JSON(The one I'm currently using):

Every time I drag a food to a "droppable" place, I call a getJSON
function to access the food data and then update the corresponding
values. This file has a 2mb size, but it surely will increase as I add
more foods to it. I'm using this option because it was the most
quickest to begin to build the app but I don't think it's a good
choice for the live app.

2) RDBMS with normalized fields:

I could create two models: Food and Nutrient, each food has 40+
nutrients related by a FK. The problem I see with this is that every
time a food data request is made, the app will hit the db a lot of
times to retrieve it.

3) RDBMS with picklefield:

This is the option I'm actually considering. I could create a Food
models and put the nutrients in a picklefield.

4) Something with Redis/Django Cache system:

I'll dive more deeply into this option. I've read some things about
them but I don't clearly know if there's some way to use them to solve
the problem I have.


Thanks in advance, Mariano.

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