Re: Accessing Models After get_model()

[Collin Anderson]

Hi,

The model name is hidden in model.__name__ or model._meta.model_name, and 
you can't access attributes starting with underscore in templates.

This might work:

from django.db.models import get_app, get_models 

def index(request):
app = get_app('sampledb')
modeldict = {model._meta.model_name: model for model in get_models(app)}
return render(request, 'sampledb/index.html', {'my_models': modeldict)

Collin

On Sunday, December 21, 2014 8:44:58 PM UTC-6, llanitedave wrote:
>
> I'm trying to display a list of the models in my app on a web page, 
> similar to the way the Django Admin does it.  I'm not sure where the admin 
> section is coded, which might be part of my problem.
>
> I'm using Django 1.7, and have built a very simple view:
>
> from django.db.models import get_app, get_models 
>
> def index(request):
> app = get_app('sampledb')
> modellist = get_models(app)
> context = {'my_models': modellist}
> return render(request, 'sampledb/index.html', context)
>
> in my index.html page I created a table:
>
> {% if my_models %}
> {{ my_models }}
> 
> 
> 
> Name
> Verbose Plural
> 
> 
> 
> {% for model in my_models %}
> 
> {{ model.name }}
> {{ model.meta.verbose_name_plural }}
> 
> {% endfor %}
> 
> 
> {% endif %}
>
>
> When I run this, my webpage first displays the {{ my_models }}, 
> showing a list of model classes, such as , 
> , etc.
>
> I guess that's my first hint that getting attributes from the 'model.name' 
> isn't going to display anything, and it doesn't.  But it doesn't give an 
> error, either.
>
> How do I dig into the class to retrieve the actual model so that I can 
> display its attributes?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ca4f0c07-9c45-406c-8cae-ad8e5906b6cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrate adds multiple migrations.AddField for same model (django 1.7.1)

[Collin Anderson]

Hi,

You're just using one database?

Are all 6 ALTER statements identical?

Collin

On Sunday, December 21, 2014 5:27:06 PM UTC-6, pjotr wrote:
>
> Just realized the subject was wrong, it should be *makemigrations , not 
> makemigrate*
>
> On Sunday, December 21, 2014 8:36:29 PM UTC+1, pjotr wrote:
>>
>> Hi,
>>
>> I have a django model that I just added six new fields to. I ran 
>> *makemigrations 
>> *and after that noticed when we ran our rehearsal upgrade with dump of 
>> the production database that things took longer than we expected, and 
>> checked the processlist. We saw that there were six *alter table* 
>> statements that was executed after each other, each taking around 15 
>> minutes to run.
>>
>> My expectations were that the migration framework would optimise this and 
>> only execute one alter table statement. But obviously it was not. Or is 
>> there a bug? :)
>>
>> Are there anyway to fix this, without having to change the migration and 
>> perform the alter table statement with pure SQL?
>>
>> DB: MySQL
>> Django 1.7.1
>>
>> The migrations generated were six of these (only showing one to reduce 
>> post size):
>>
>> migrations.AddField(
>> model_name='mymodel',
>> name='field_a',
>> field=models.BigIntegerField(help_text=b'Blablabla', null=True, 
>> db_index=True),
>> preserve_default=True,
>> ),
>>
>>
>> Regards, Peter Lauri
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/713e93b9-b7e3-4f4d-b8ec-b34046cf34e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model form with optional fields issue

[James Schneider]

That seems like a bit of a broad brush stroke against Django. Have you
looked at the Django REST Framework module? It can often utilize your
existing views, and has support for partial updates.

http://www.django-rest-framework.org/api-guide/serializers/#partial-updates

Django is primarily used for displaying/validating data received from HTML
forms, hence the bias towards that behavior where partial updates are not
common. However, the internal behavior is decoupled enough that the
behavior you desire can be easily attained, hence the Django REST Framework.

-James
On Dec 22, 2014 9:14 AM,  wrote:

>
>> > What do you think - is this expected?
>>
>> Yes, this is expected. Django's form system is designed for use with
>> HTML forms, which do not provide partial data: unchanged field values
>> are sent too, so this problem does not occur.
>>
>
> I thought that Web framework can validate RESTful(-like) requests (like
> PATCH or even GET), but I see that without redesigning/overriding built-in
> forms it is not possible.. :(
>
> I would like to say that in my opinion validation and cleaning (forms
> essentials) should be decoupled from HTML input and rendering.
> Without that, forms are only partially usable. It's a design issue, IMO.
>
> Nowdays I'm creating more apps with separated clients written in pure js,
> and I need solid backend.
> Input cleaning, validation and processing logic is the most important
> thing.
> But with validation designed mostly for plain-old-html input I can't rely
> on Django as a web framework.
> That's sad, because I like it for rapid development.
>
> Kind Regards,
> /Marcin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d15de090-649f-4e95-9262-f2f22462598f%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUogS2FsmYKxfSkAFdfAJKeo4_rNivY6qbP%2B16SmV-POw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to Display the number of active users in Django Site with IP address

[Collin Anderson]

Hi,

Something like this might be a start:

class UserIP(models.Model):
user = models.ForeignKey(User)
ip = models.GenericIPAddressField()
last_seen = models.DateTimeField(auto_now=True)

class Middleware(pass):
def process_response(request, response):
if request.user:  # or getattr(request, '_cached_user')
UserIP.objects.create_or_update(user=request.user, ip=request.
META['REMOTE_ADDR'])
return response

Collin

On Sunday, December 21, 2014 7:30:33 AM UTC-6, Avinash Kunuje wrote:
>
> How to Display the number of active users in Django Site with IP address
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bd4d971c-d5f4-409b-bec4-96427c3841f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Random row

[Collin Anderson]

Hi,

Are you sure you saved your code? There's a len() in your traceback that 
isn't in your code.

Collin


On Saturday, December 20, 2014 3:50:11 PM UTC-6, Dariusz Mysior wrote:
>
> I change it on
>
> import csv, random
>
> def new_name():
> with open('PL_surnames.csv', newline='') as csvfile:
> namesreader = csv.reader(csvfile, delimiter=' ', quotechar='|') 
> 
> random_choice=random.choice(namesreader)
> return random_choice
> print(new_name())
>
>
>
> No I have this message
>
> Traceback (most recent call last):
>   File "C:/Python31/csv", line 10, in 
> print(new_name())
>   File "C:/Python31/csv", line 8, in new_name
> random_choice=random.choice(namesreader*len(namesreader))
> TypeError: object of type '_csv.reader' has no len()
> >>> 
>
>
>
> W dniu sobota, 20 grudnia 2014 22:37:23 UTC+1 użytkownik Dariusz Mysior 
> napisał:
>>
>> Why I get only last row from my csv file, why I don't get in any time 
>> ranom row :/
>>
>> import csv, random
>>
>> def new_name():
>> with open('PL_surnames.csv', newline='') as csvfile:
>> namesreader = csv.reader(csvfile, delimiter=' ', quotechar='|') 
>> for row in namesreader:
>> #print (','.join(row))
>> random_choice=random.choice(row)
>> return random_choice
>> print(new_name())
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/789c3575-b89a-48c1-b0c8-4ac0ac56087b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: (yet another) Custom templatetag raising KeyError when DEBUG=False

[Collin Anderson]

Hi,

Do you have more of your traceback?

Are you sure this is your "home" view that's being called?

Is this happening in an included template?

Collin

On Saturday, December 20, 2014 3:27:00 PM UTC-6, Alexandre Provencio wrote:
>
> Hello all, this is a cross post i made on stackoverflow 
>
> http://stackoverflow.com/questions/27503581/yet-another-custom-templatetag-raising-keyerror-when-debug-false
>  
>
> I'm trying to use a custom templatetag (this one actually: 
> https://djangosnippets.org/snippets/2875/), on my project which works 
> fine as long as DEBUG=True. When it's False, the relevant error part 
> is: 
>
> File "...app/templatetags/helper_tags.py", line 15, in change_lang 
> path = context['request'].path 
> File "...local/lib/python2.7/site-packages/django/template/context.py", 
> line 56, in __getitem__ 
> raise KeyError(key) 
> KeyError: 'request' 
>
> I've seen a lot of questions like this and I have already done the 
> settings that all of them seen to suggest which are: 
>
> 1) views.py uses django.shortcuts.render: 
>
> from django.shortcuts import render 
> def home(request): 
> return render(request, 'home.html') 
>
> 2) settings.py contains: 
>
> ALLOWED_HOSTS = ['*'] 
>
> from django.conf import global_settings 
> TEMPLATE_CONTEXT_PROCESSORS = global_settings.TEMPLATE_CONTEXT_PROCESSORS 
> + ( 
> "django.core.context_processors.request", 
> ) 
>
> I've also created a new project with the same Django version (1.6.2) 
> that tries to imitate the problematic project as much as possible, and 
> for my despair it works fine also when DEBUG=False. 
>
> Any hints on this is very much appreciated. 
>
> Cheers! 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e1236721-cc22-4554-82b6-ddb2a9d068e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Problem with google calendar on ancient django version

[Roy Smith]

I'm in the process of incrementally upgrading a site running some ancient 
software (django 1.3.1 and django-cms 2.2).  I've got a development version of 
the site running django-cms 2.3.8 (and still django 1.3.1) for testing.  The 
plan is to get it up to modern versions of both, but one step at a time.  One 
oddity is see in the newer site, my google calendar is missing some of the 
icons.   The problem is that

https://calendar.google.com/googlecalendar/images/combined_v22.png

(a bunch of sprited images) is failing to load on the 2.3.8 site, with 
"net::ERR_BLOCKED_BY_CLIENT" showing in the javascript console.  The referrer 
URL for that is

https://www.google.com/calendar/static/7f25774200d4fe9fa8584b21c00791ffe

so it's clear this is some kind of cross-domain problem.  The questions are:

1) Has anybody else seen this?

2) Why did changing the django-cms version change how this behaves?

3) Is this fixed in later django-cms versions?

4) Is this fundamentally a bug in Google calendar, i.e. I should be reporting 
it to them?

--
Roy Smith
r...@panix.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2FFD57A2-8E18-406A-8F02-A1D176B21B41%40panix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database queries location

[Collin Anderson]

Hi,

There's a good example of creating a custom manager here:
https://docs.djangoproject.com/en/dev/topics/db/managers/#custom-managers

Collin

On Saturday, December 20, 2014 8:28:57 AM UTC-6, pythonista wrote:
>
> Thank you for your response.  
>
> Most of my data is complex raw sql.
> I had placed it in the views and it is working as expected
>
> I would like to migrate the raw sql to managers, 
> Can you point me to one or more good examples of how the manager is coded 
> and how the sql interacts with the views.
>
> Thanks
>
>
> On Friday, December 19, 2014 7:06:54 AM UTC-5, aRkadeFR wrote:
>>
>> Depend exactly on what to compute for your post data. 
>>
>> I would almost write no logic code in the views. 
>>
>> I split every application as follow: 
>> - managers.py: All the logic as a table level (raw SQL, complex queries) 
>> - models.py: All logic as a row level / object level (python computing 
>> data) 
>> - forms.py: All logic as forms data / processing / validation for 
>> request data 
>>
>> Have a good one, 
>>
>> aRkadeFR 
>>
>> On 12/18/2014 10:12 PM, pythonista wrote: 
>> > I understand that functions can be placed in the models fille 
>> > 
>> > However if I have complex queries that receive post input does the 
>> > 
>> > 
>> > Query live in the model  the views or an external module 
>> > 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/addb9d99-6d6e-4198-80e3-b176b2707e02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Poll Tutorial (for Django 1.7) Files Available?

[Ken Wayne]

I'm trying to work through the Poll Tutorial and I've run into some 
problems.  I'd like to compare the code I've written to a working file.  Is 
there any place to download the entire working project?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/26f1c16c-865c-43a6-910e-5dd90beb22bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Fergus Cameron]

On 22/12/2014, Alasdair Nicol  wrote:
> [ ... ]
>  > In Django 1.7, the trailing dot is stripped when performing host
>  > validation, thus an entry with a trailing dot isn’t required.

How odd, since the canonical representation would be to add a dot when
one is missing rather than removing it when one is present.  I suppose
convention superceeds, oh well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHCf7OFrJeJ9qSHmk3CRa1ihJQwvpuv3JkmFxZwCDToJ5ecMng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thinking about EAV database model for flexibility. How (in)compatible is it with the django model?

[Jamie Lawrence]

Well, Django, in the role of an ORM, is necessarily pretty coupled to SQL. I 
know people have been toying with nosql databases with Django; I don't know 
much about those efforts. 

EAV intentionally defeats the intended use of RDBMSes by ignoring normalization 
and data typing, thus (among other things) losing easy queryability, validation 
and performance  optimizations designed with structure in mind. You can butter 
bread with lumber, but doing so is likely to be a little problematic.  

So, to answer your question, 'both'. 

I would imagine a fully nosql-capable Django would rethink the model system 
quite a bit, given that the capabilities and use cases of nosql systems are 
rather divergent from RMDBSes (and frequently each other).

I know it is common to 'pick a side'. But nosql databases are different beasts, 
good at different things. Doing things like storing sessions in Mysql (say) on 
a heavily loaded site is almost always a bad idea in any case. 

-j


> On Dec 22, 2014, at 2:27 AM, Felipe Faraggi  wrote:
> 
> I'd like to 're-open' this question to ask another (maybe) short one:
> 
> Therefore, is django not very suitable for NOSQL databases like mongo or 
> couch or others in general?
> Or is the problem specifically using RDBMS in a NoSQL manner?
> 
> Because if using NOSQL, the whole model system would be obsolete. Am I wrong 
> in this line of thinking?
> 
> 
> thanks in advance!
> 
> 
>> On Tuesday, December 16, 2014 11:24:12 AM UTC+1, Felipe Faraggi wrote:
>> Thanks for your responses Jamie and Erik,
>> 
>> We've since reconsidered and will in fact, be creating a standard relational 
>> structure. 
>> 
>> Again, thanks for your input and feedback
>> 
>> 
>> 
>> 
>>> On Tuesday, December 16, 2014 2:18:12 AM UTC+1, Jamie Lawrence wrote:
>>> Just to add to Erik's very good advice on (not) using EAV, another thing to 
>>> keep in mind is that the downsides of EAV tend to manifest after your app 
>>> is hosting a substantial amount of data, at which point the exercise of 
>>> sanitizing it in order to port it to a saner model can be *excruciating*. 
>>> 
>>> I've come in to projects like this as a consultant and the golden rule of 
>>> any such contract is "no cap on data conversion fees, but please feel free 
>>> to do it yourself once you realize how much it will cost to preserve that 
>>> data."
>>> 
>>> More generally, when using a relational database, you want to think hard 
>>> about temptations to store things in generic buckets. There is a data store 
>>> optimized for generic buckets of bits; it is called a file system. Rdbmses, 
>>> not being designed for that, tend to become expensive[1] when forced to act 
>>> like it. 
>>> 
>>> -j
>>> 
>>> [1] not necessarily in currency, but that can certainly happen as well. 
>>> 
>>> -- 
>>> Sent from a phone, please excuse typos and terseness.
>>> 
 On Dec 15, 2014, at 5:42 AM, Felipe Faraggi  wrote:
 
 Hello everybody.
 
 I am very new to django and I come from a wordpress background (yes, yes I 
 know) and I really like their wp_*meta model. 
 
 After a little digging I discovered this is called the 
 Entity-attribute-value model or EAV. And I am currently setting up a 
 project in django in which my data is very variable because we will be 
 opening up to many APIs and they all have their own table styles. So 
 instead of having a rigid model, we've opted for having a EAV model to 
 stock everything with its own key-value pair.
 
 So I would like to hear your general thoughts about this method (I've 
 heard some good/bad things about it) and your specific experiences with it 
 and django (if any).
 
 I found this repository https://github.com/mvpdev/django-eav that I could 
 use as reference.
 
 Thanks!
 -- 
 You received this message because you are subscribed to the Google Groups 
 "Django users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to django-users...@googlegroups.com.
 To post to this group, send email to django...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-users.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-users/f0c8def8-d577-4f37-8e67-17fdae896219%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 users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/9d4e1cec-2745-470c-87ec-3998de078073%40googlegroups.com.
> For more options, visit https://gro

Re: Thinking about EAV database model for flexibility. How (in)compatible is it with the django model?

[Erik Cederstrand]

> Den 22/12/2014 kl. 11.27 skrev Felipe Faraggi :
> 
> I'd like to 're-open' this question to ask another (maybe) short one:
> 
> Therefore, is django not very suitable for NOSQL databases like mongo or 
> couch or others in general?
> Or is the problem specifically using RDBMS in a NoSQL manner?

I haven't used Django with NoSQL, so I can't answer that specific question. The 
Django wiki has a page on NoSQL: 
https://code.djangoproject.com/wiki/NoSqlSupport

Which "problem" you are referring to? If you mean using an EAV in Django then 
the problem is not in Django as such, but rather that an EAV usually ends up 
being a miserable way of storing your data, regardless of which software you 
choose to implement it with.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7888B586-E853-4B5D-A325-34CF166CF1D2%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Raw access to cache table

[Erik Cederstrand]

Hi Russel,

> Den 22/12/2014 kl. 00.40 skrev Russell Keith-Magee :
> 
> If you *do* want to do complex queries on the database cache table, the 
> approach suggested by Collin is as good an approach as any. A managed table 
> will give you ORM operations over an arbitrary table - include Django's own 
> internal tables.
> 
> That said, I'll also concur that the database cache backend is the wrong 
> answer here. If you're writing a cron script, the approach I've always used 
> is PIDfile based lock

Thanks for taking the time to explain the design considerations for the cache 
mechanism.

I agree that using the cache to hold locks is a bit awkward, but DB 
transactions would be running way too long for my taste, and I can't use 
pidfile locks because my dataset can get updates from both cron jobs and my 
REST API. But I should probably take a hard look at my design again.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0D2D0B45-A5A7-454D-8173-5F71566AB3C8%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Raw access to cache table

[Erik Cederstrand]

Hi Colin,

> Den 21/12/2014 kl. 05.55 skrev Collin Anderson :
> 
> If you want a nicer interface, I just ran manage.py inspecdb on one of my 
> databases and got this for the cache table. Not sure why django still does it 
> by hand.
> 
> class Cache(models.Model):
> cache_key = models.CharField(primary_key=True, max_length=255)
> value = models.TextField()
> expires = models.DateTimeField()
> 
> class Meta:
> managed = False
> db_table = 'cache_table'

Thanks, that's actually a nice trick. I'd still need to un-pickle the values, 
but I can use the ORM to query cache_key.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/F3C4ED56-811D-46EB-83D4-B76E0A252B40%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Foked Django Mezzanine with Query-less database SearchQuerySet integration [Gazelle]

[Robert Steckroth]

Hello community, I wanted to show interest in collaborating on an
opensource Django application called Gazelle (a fork of Mezzanine).
I built a SearchQuerySet with a drop in replacement to the filter() command
which does not hit the database.
So, far the results are promising and I am opening the project up at this
point. Anyone in the Django community
should at least bookmark the SearchQuerySet file linked below if
contributing to the remake is not feasible.

There is a lot of work to do so this may just end up being a better
Mezzanine project instead of a complete "remake".

https://bitbucket.org/surgemcgee/django-mezzanine-gazebo/src/6945aa45b34d30304224c8edf40915d964f0c519/mezzanine/utils/values_filter.py?at=master


-- 


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAL-VaPc973fzsvJwNGxCWW3ZwJrainaq_NeQMtqwoFAAEGMHtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ModelAdmin with inlines: How to learn if/what has changed before the models are saved?

[Carsten Fuchs]

Hi Alex,

Am 20.12.2014 um 22:47 schrieb Alex Haylock:

Take a look at the Django signal dispatcher:
https://docs.djangoproject.com/en/dev/topics/signals/

Specifically, the 'update_fields' argument passed to the 'pre_save'
signal should provide what you need:

https://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.pre_save


Many thanks for your reply!

While I seem to understand signals generally, I followed Collin's 
suggestion, because the ModelAdmin class already has so many readily 
available customization callbacks, so that this eventually looked a bit 
more straightforward to me.


Also, the big question that occurred to me when I (re-)read the signals 
documentation that you linked above was this description for the 
`update_fields` argument:
“The set of fields to update explicitly specified in the save() 
method. None if this argument was not used in the save() call.“


To be honest, I did not fully set it up to try it out, but in the 
ModelAdmin source I saw that the model's save() method is plainly 
called, without any explicit parameters. This would have rendered the 
`update_fields` useless, and left me with no way to figure out what has 
changed in the model when the pre_save signal is received, right?


Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54985876.9040805%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: ModelAdmin with inlines: How to learn if/what has changed before the models are saved?

[Carsten Fuchs]

Hi Collin,

Am 20.12.2014 um 00:18 schrieb Collin Anderson:

save_model() happens first, then save_related() which
calls save_formset() on each formset.

It might end up being easier to save the parent model _again_, instead
of doing something before it's saved.


Thank you very much for your reply, that helped a lot!


_has_changed() / has_changed() may come in handy in your case.
https://docs.djangoproject.com/en/dev/ref/forms/fields/#has-changed


In Django 1.7, it seems that _has_changed() takes several parameters 
that I had not readily available, so I eventually looked this up in the 
Django 1.7 source code (django/forms/forms.py), and now instead of, for 
example (probably valid Django 1.8 code):


if form.fields['birthday'].has_changed():  ...

with Django 1.7 I use:

if "birthday" in form.changed_data:  ...

which works very well!

Thanks again for your help!

   :-)

Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54985604.5040903%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: Model form with optional fields issue

[marcin . j . nowak]

>
>
> > What do you think - is this expected? 
>
> Yes, this is expected. Django's form system is designed for use with 
> HTML forms, which do not provide partial data: unchanged field values 
> are sent too, so this problem does not occur. 
>

I thought that Web framework can validate RESTful(-like) requests (like 
PATCH or even GET), but I see that without redesigning/overriding built-in 
forms it is not possible.. :(

I would like to say that in my opinion validation and cleaning (forms 
essentials) should be decoupled from HTML input and rendering. 
Without that, forms are only partially usable. It's a design issue, IMO.

Nowdays I'm creating more apps with separated clients written in pure js, 
and I need solid backend. 
Input cleaning, validation and processing logic is the most important thing.
But with validation designed mostly for plain-old-html input I can't rely 
on Django as a web framework.
That's sad, because I like it for rapid development. 

Kind Regards,
/Marcin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d15de090-649f-4e95-9262-f2f22462598f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Difference between Q and filter and exclude

[Larry Martell]

Is there any difference, either functional or performance wise,
between these 2 constructs:

Q(f=1) and filter(f=1)

Or, between these 2:

(~Q(f=1)) and exclude(f=1)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACwCsY6YZmJAihQGavHv274G1HAPx5T1oJ_%3DoJ2BFfPP7Ag0jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Alex Haylock]

Thanks Alasdair, that's really useful. I'm using v1.6.X in production,
which makes sense based on your email.

Alex.

On 22/12/14 13:58, Alasdair Nicol wrote:
> Hi Alex,
> 
> There is no security implication adding 'example.com.' (with trailing
> dot) to your ALLOWED_HOSTS setting. There is some more information in
> the ALLOWED_HOSTS setting docs.
> 
> From https://docs.djangoproject.com/en/1.7/ref/settings/#allowed-hosts
> 
>> In previous [<= 1.6.X] versions of Django, if you wanted to also
>> allow the fully qualified domain name (FQDN), which some browsers
>> can send inthe Host header, you had to explicitly add another
>> ALLOWED_HOSTS entry that included a trailing period.
> 
>> In Django 1.7, the trailing dot is stripped when performing host
>> validation, thus an entry with a trailing dot isn’t required.
> 
> cheers,
> Alasdair
> 
> 
> 
> On 22/12/14 12:05, Alex Haylock wrote:
>> Thanks Markus.
>>
>> So, as per the RFC, are 'example.com' and 'example.com.' considered to
>> be the same domain, or two separate domains?
>>
>> Are there any security implications if I add 'example.com.' to
>> ALLOWED_HOSTS to cater for these requests?
>>
>> Thanks,
>>
>> Alex.
>>
>> On 22/12/14 11:52, Markus Holtermann wrote:
>>> Hey Alex,
>>>
>>> a trailing . in the host header is valid per RFC 3986:
>>> http://tools.ietf.org/html/rfc3986#section-3.2.2:
>>>
>>>  The rightmost domain label of a fully qualified domain name in DNS
>>>  may be followed by a single "."
>>>
>>>
>>> /Markus
>>>
>>> On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:
>>>
>>>  Are there any known attack vectors that involve appending a period/
>>>  full-stop to a sites domain name?
>>>
>>>  My Django application throws a handful of errors in production
>>> every
>>>  day:
>>>
>>>  ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may
>>> need to
>>>  add
>>>  u'www.example.com .' to ALLOWED_HOSTS.
>>>
>>>  (note the trailing period)
>>>
>>>  Is this malicious behaviour, or just users mistyping the URL?
>>>
>>>  Also, browsers are clearly treating the final '.' as part of the
>>> path
>>>  (as these requests are reaching my application), but Django is
>>> treating
>>>  the '.' as part of the hostname. Which is right?
>>>
>>>  --
>>>  Regards,
>>>
>>>
>>>  Alex
>>>
>>
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54982E97.3040803%40mykolab.com.
For more options, visit https://groups.google.com/d/optout.

Re: filter Datetimefield

[Jan Duzinkiewicz]

It's hard to answer without seeing what's in your db, and what are the 
values of ano/mes/dia variables, but:
 - maybe you do not have pytz package installed (you can install with 'pip 
install pytz') - though in that case you should get an error when trying to 
access the results
 - maybe the day and month in db are different than what you are querying 
for?

Does the same method called in django-shell returns some results - if so, 
maybe there's some logic in your view that prevents non-empty results to be 
displayed?
If that does not help, try posting the results of Model.objects.all and 
your view - that should help in troubleshooting.


W dniu niedziela, 21 grudnia 2014 15:04:49 UTC+1 użytkownik Rafael Borella 
napisał:
>
> Hi,  i'm new in django and python,
>
> I'm trying to create a queryset to filter according to date.
>
> this is my MODEL :  data = models.DateTimeField()
>
> and my VIEW:def resultado(request, dia, mes, ano):
>lista_de_balada= 
> Balada.objects.filter(data__year=ano, data__month=mes, data__day=dia)
>context = {'lista_de_balada':lista_de_balada}
>return render(request, 'procurar.htm', context)
>
> it presents no errors, but the query is aways empty...if i take off   
> __month 
> and__day  it works fine.   but i need to filter according to date 
>  not only year.
>
> Sorry for the english, is not my native language.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/44cc0f80-920e-43c6-a2e8-db9c7b817901%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Alasdair Nicol]

Hi Alex,

There is no security implication adding 'example.com.' (with trailing 
dot) to your ALLOWED_HOSTS setting. There is some more information in 
the ALLOWED_HOSTS setting docs.


From https://docs.djangoproject.com/en/1.7/ref/settings/#allowed-hosts


In previous [<= 1.6.X] versions of Django, if you wanted to also

> allow the fully qualified domain name (FQDN), which some browsers

can send inthe Host header, you had to explicitly add another

> ALLOWED_HOSTS entry that included a trailing period.

> In Django 1.7, the trailing dot is stripped when performing host
> validation, thus an entry with a trailing dot isn’t required.

cheers,
Alasdair



On 22/12/14 12:05, Alex Haylock wrote:

Thanks Markus.

So, as per the RFC, are 'example.com' and 'example.com.' considered to
be the same domain, or two separate domains?

Are there any security implications if I add 'example.com.' to
ALLOWED_HOSTS to cater for these requests?

Thanks,

Alex.

On 22/12/14 11:52, Markus Holtermann wrote:

Hey Alex,

a trailing . in the host header is valid per RFC 3986:
http://tools.ietf.org/html/rfc3986#section-3.2.2:

 The rightmost domain label of a fully qualified domain name in DNS
 may be followed by a single "."


/Markus

On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:

 Are there any known attack vectors that involve appending a period/
 full-stop to a sites domain name?

 My Django application throws a handful of errors in production every
 day:

 ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to
 add
 u'www.example.com .' to ALLOWED_HOSTS.

 (note the trailing period)

 Is this malicious behaviour, or just users mistyping the URL?

 Also, browsers are clearly treating the final '.' as part of the path
 (as these requests are reaching my application), but Django is treating
 the '.' as part of the hostname. Which is right?

 --
 Regards,


 Alex






--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54982391.6050604%40memset.com.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Mark Phillips]

Alex,

The trailing period could be from online promotional materials for your
site. Someone may have written your URL with the trailing period inside the
URL by mistake when the promotional materials were created. It may not be
an attack vector from a malicious hacker, but instead, valid users just
clicking on a link that contains a URL for your site with the trailing
period.

Mark

On Mon, Dec 22, 2014 at 4:43 AM, Alex Haylock 
wrote:

> Are there any known attack vectors that involve appending a period/
> full-stop to a sites domain name?
>
> My Django application throws a handful of errors in production every day:
>
> ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to add
> u'www.example.com.' to ALLOWED_HOSTS.
>
> (note the trailing period)
>
> Is this malicious behaviour, or just users mistyping the URL?
>
> Also, browsers are clearly treating the final '.' as part of the path
> (as these requests are reaching my application), but Django is treating
> the '.' as part of the hostname. Which is right?
>
> --
> Regards,
>
>
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/549803CE.7060208%40mykolab.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEqej2P1%3DvY_E97id-jVRAqrkHAV0Qx0kE9U6OPO82OAMq1Vzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Alex Haylock]

Thanks Markus.

So, as per the RFC, are 'example.com' and 'example.com.' considered to
be the same domain, or two separate domains?

Are there any security implications if I add 'example.com.' to
ALLOWED_HOSTS to cater for these requests?

Thanks,

Alex.

On 22/12/14 11:52, Markus Holtermann wrote:
> Hey Alex,
> 
> a trailing . in the host header is valid per RFC 3986:
> http://tools.ietf.org/html/rfc3986#section-3.2.2:
> 
> The rightmost domain label of a fully qualified domain name in DNS
> may be followed by a single "."
> 
> 
> /Markus 
> 
> On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:
> 
> Are there any known attack vectors that involve appending a period/
> full-stop to a sites domain name?
> 
> My Django application throws a handful of errors in production every
> day:
> 
> ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to
> add
> u'www.example.com .' to ALLOWED_HOSTS.
> 
> (note the trailing period)
> 
> Is this malicious behaviour, or just users mistyping the URL?
> 
> Also, browsers are clearly treating the final '.' as part of the path
> (as these requests are reaching my application), but Django is treating
> the '.' as part of the hostname. Which is right?
> 
> -- 
> Regards,
> 
> 
> Alex
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/549808F9.4010607%40mykolab.com.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Markus Holtermann]

Hey Alex,

a trailing . in the host header is valid per RFC 3986: 
http://tools.ietf.org/html/rfc3986#section-3.2.2:

The rightmost domain label of a fully qualified domain name in DNS may be 
> followed by a single "."


/Markus 

On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:
>
> Are there any known attack vectors that involve appending a period/ 
> full-stop to a sites domain name? 
>
> My Django application throws a handful of errors in production every day: 
>
> ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to add 
> u'www.example.com.' to ALLOWED_HOSTS. 
>
> (note the trailing period) 
>
> Is this malicious behaviour, or just users mistyping the URL? 
>
> Also, browsers are clearly treating the final '.' as part of the path 
> (as these requests are reaching my application), but Django is treating 
> the '.' as part of the hostname. Which is right? 
>
> -- 
> Regards, 
>
>
> Alex 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0ff75680-cdc4-49d8-8bdd-c4d727213921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

malicious requests?

[Alex Haylock]

Are there any known attack vectors that involve appending a period/
full-stop to a sites domain name?

My Django application throws a handful of errors in production every day:

ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to add
u'www.example.com.' to ALLOWED_HOSTS.

(note the trailing period)

Is this malicious behaviour, or just users mistyping the URL?

Also, browsers are clearly treating the final '.' as part of the path
(as these requests are reaching my application), but Django is treating
the '.' as part of the hostname. Which is right?

-- 
Regards,


Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/549803CE.7060208%40mykolab.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can't open manage.py

[Valéria Pacheco]

tks! that was it! Sorry for the ignorance, but i'm starting with python too!

Sexta-feira, 19 de Dezembro de 2014 12:00:01 UTC, Guilherme Leal escreveu:
>
> Are you sure that your shell is running on the same folder that contains 
> the manage.py?
>
> Em Fri Dec 19 2014 at 09:53:05, Valéria Pacheco  > escreveu:
>
>> I ran this command $ python manage.py migrate 
>>
>> and the following error occurs
>>
>> python: can't open file 'manage.py': [Errno 2] No such file or directory
>>
>>
>> The file exists though.
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/26f2a151-f068-4a0b-bc97-97671401a6d0%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c61fb4b7-bf86-43d2-a074-28fd00e96d45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thinking about EAV database model for flexibility. How (in)compatible is it with the django model?

[Felipe Faraggi]

I'd like to 're-open' this question to ask another (maybe) short one:

Therefore, is django not very suitable for NOSQL databases like mongo or 
couch or others in general?
Or is the problem specifically using RDBMS in a NoSQL manner?

Because if using NOSQL, the whole model system would be obsolete. Am I 
wrong in this line of thinking?


thanks in advance!


On Tuesday, December 16, 2014 11:24:12 AM UTC+1, Felipe Faraggi wrote:
>
> Thanks for your responses Jamie and Erik,
>
> We've since reconsidered and will in fact, be creating a standard 
> relational structure. 
>
> Again, thanks for your input and feedback
>
>
>
>
> On Tuesday, December 16, 2014 2:18:12 AM UTC+1, Jamie Lawrence wrote:
>>
>> Just to add to Erik's very good advice on (not) using EAV, another thing 
>> to keep in mind is that the downsides of EAV tend to manifest after your 
>> app is hosting a substantial amount of data, at which point the exercise of 
>> sanitizing it in order to port it to a saner model can be *excruciating*. 
>>
>> I've come in to projects like this as a consultant and the golden rule of 
>> any such contract is "no cap on data conversion fees, but please feel free 
>> to do it yourself once you realize how much it will cost to preserve that 
>> data."
>>
>> More generally, when using a relational database, you want to think hard 
>> about temptations to store things in generic buckets. There is a data store 
>> optimized for generic buckets of bits; it is called a file system. Rdbmses, 
>> not being designed for that, tend to become expensive[1] when forced to act 
>> like it. 
>>
>> -j
>>
>> [1] not necessarily in currency, but that can certainly happen as well. 
>>
>> -- 
>> Sent from a phone, please excuse typos and terseness.
>>
>> On Dec 15, 2014, at 5:42 AM, Felipe Faraggi  wrote:
>>
>> Hello everybody.
>>
>> I am very new to django and I come from a wordpress background (yes, yes 
>> I know) and I really like their wp_*meta model. 
>>
>> After a little digging I discovered this is called the 
>> Entity-attribute-value 
>> model or EAV 
>> . 
>> And I am currently setting up a project in django in which my data is very 
>> variable because we will be opening up to many APIs and they all have their 
>> own table styles. So instead of having a rigid model, we've opted for 
>> having a EAV model to stock everything with its own key-value pair.
>>
>> So I would like to hear your general thoughts about this method (I've 
>> heard some good/bad things about it) and your specific experiences with it 
>> and django (if any).
>>
>> I found this repository https://github.com/mvpdev/django-eav that I 
>> could use as reference.
>>
>> Thanks!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/f0c8def8-d577-4f37-8e67-17fdae896219%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9d4e1cec-2745-470c-87ec-3998de078073%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.