Develop Reference

Is it possible to generate hash from a queryset?

My idea is to create a hash of a queryset result. For example, product inventory.
Each update of this stock would generate a hash.
This use would be intended to only request this queryset in the API, when there is a change (example: a new product in invetory).
Example for this use:
no change, same hash - no request to get queryset
there was change, different hash. Then a request will be made.
This would be a feature designed for those who are consuming the data and not for the Django that is serving.
Does this make any sense? I saw that in python there is a way to generate a hash from a tuple, in my case it would be to use the frozenset and generate the hash. I don't know if it's a good idea.

I would comment, but I'm waiting on the 50 rep to be able to do that. It sounds like you're trying to cache results so you aren't querying on data that hasn't been changed. If you're not familiar with caching, the idea is to save hard-to-compute answers in memory for frequently queried endpoints/functions.
For example, if I had a program that calculated the first n digits of pi, I may choose to save a map of [digit count -> value] so that if 10 people asked me for the first thousand, I would only calculate it once. Redis is a popular option for caching, and I believe it exists for Django. It allows you to cache some information, set a time before expiration on it, and then wipe specific parts of that information (to force it to recalculate) every time something specific changes (like a new product in inventory).
Everybody should try writing their own cache at least once, like what you're describing, but the de facto professional option is to use a caching library. Your idea is good, it will definitely work, and you will probably want a dict of [hash->result] for each hash, where result is the information you would send back over your API. If you plan to save data so it persists across multiple program starts, remember Python forces random seeds for hashes, causing inconsistent values. Check out this post for more info.

django cache key naming

I want to store some items using Django cache API. Are there are best practices to follow while naming the key. I know some people just give user name as the key. But I am going to cache various items in different views and having the same key every where is not feasible. I was thinking on may be giving a key with username+ 'some view specific' so that the key can be unique.
Does any one have any other good suggestions for generating keys?

Generation of keys can depend on what you are tying to achieve.
Is what the user is trying to access for that user only?
Is what the user is trying to access generic for all the users?
e.g.
let's say you are trying to access a url:
http://yourserver/endpoint/?filter1=value1&filter2=value2
In the above case, you can use the query params filter1=value1&filter2=value2 to create a cached key (by generating the md5 hash).
Considering the two options earlier, if the view should return some data specific to the user then you can also append the user id to create a unique key for the user.
Another example could be a url like this, where one is trying to access all the articles from source 1:
http://yourserver/source/1/articles/?filter1=value1&filter2=value2
In this case it might also be useful to append the cache key with the source id (so this uses the context data for the views in generating the keys).

AppEngine model structure for user/follower relations

I have a users who have "followers". I need to be able to navigate up and down the tree of users/followers. I'm eventually going hit AppEngine's 1mb limit on entity entries if I use ancestor relations if a user has many followers.
What's the best way to structure this data on AppEngine?

You cannot use ancestor relations for a simple reason that your use case allows circular references (I follow you, you follow me).
The solution depends on your expected usage patterns. You can choose between two options:
(A) In each suer entity store a list of IDs of other users that this user is following.
(B) Create a separate entity that has two properties: "User" and"Follower". Every entity will represent a single "connection" between users.
While the first option seems simpler, you may run into exploding indexes problem. Besides, it may turn out to be a more expensive solution as each change in user relationships will require an overwrite of a user entity with updates to all of its other indexes. The second solution does not have these drawbacks, but may require a little extra code.

to store the data in the tables in django app without default ordering

my code:
for name, count1 in list:
s = Keywords(file_name=name,frequency_count=count1)
s.save()
this is a section of code in views.py file of my app created in django. In this section, it is the way I'm storing the data in the table. This data is stored in the increasing order of the filenames which I do not want. I tried using order_by() function without any arguments but no effect. The data is still stored in increasing order. Please suggest some solution.
I'm new to django and sqlite3. So,
please help.

Order is inextricable. The queryset is always going to be ordered by something, even if it's just the default of the primary key. This is really a database thing more than a Django thing. Databases inherently order data by the primary key unless told to order by something else. If you want truly random ordering, then you can use order_by('?'), but that significantly increases the work the the database has to do.

ISBNs are used as primary key, now I want to add non-book things to the DB - should I migrate to EAN?

I built an inventory database where ISBN numbers are the primary keys for the items. This worked great for a while as the items were books. Now I want to add non-books. some of the non-books have EANs or ISSNs, some do not.
It's in PostgreSQL with django apps for the frontend and JSON api, plus a few supporting python command-line tools for management. the items in question are mostly books and artist prints, some of which are self-published.
What is nice about using ISBNs as primary keys is that in on top of relational integrity, you get lots of handy utilities for validating ISBNs, automatically looking up missing or additional information on the book items, etcetera, many of which I've taken advantage. some such tools are off-the-shelf (PyISBN, PyAWS etc) and some are hand-rolled -- I tried to keep all of these parts nice and decoupled, but you know how things can get.
I couldn't find anything online about 'private ISBNs' or 'self-assigned ISBNs' but that's the sort of thing I was interested in doing. I doubt that's what I'll settle on, since there is already an apparent run on ISBN numbers.
should I retool everything for EAN numbers, or migrate off ISBNs as primary keys in general? if anyone has any experience with working with these systems, I'd love to hear about it, your advice is most welcome.

I don't know postgres but normally ISBM would be a unique index key but not the primary. It's better to have an integer as primary/foreign key. That way you only need to add a new field EAN/ISSN as nullable.

I agree with the_lotus, not least because ISBN is a poor choice for primary key
Data wise, it may not be unique enough. If clustered, it's quite wide and non-numeric
Example

If you're using ISBN-10s, then you definitely should migrate to something else, as those are already deprecated. You can easily take ISBN-10s and turn them into ISBN-13s (see wikipedia), which I think are EAN-compatible (again, see wikipedia), but as the_lotus suggests, it's probably better to have some sort of auto-incrementing integer with no external meaning as the primary key and then index on the EAN/ISBN/etc.

A simple solution (although arguably whether good) would be to use (isbn,title) or (isbn,author) which should pretty much guarantee uniqueness. Ideology is great but practicality also serves a purpose.