online transactions with python

Well...

I'm form Perú and nowadays I'm working with my friends on a proyect
based on python...

but our first difficulty its the online transactions using credit
cards (visa, mastercard, diners club) in aweb store

If anybody knows something or can help me... please send me an email.

Thanks

--
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.

Creating a hierarchy of objects in my api.py

Hello,

I am playing around with tastypie and i want to create a hierarchy of
data.

What i currently have is this:

class keywordResource(ModelResource):
tweets = fields.ToManyField(timelineResource, 'tweets', full=True)
class Meta:
queryset = Keyword.objects.all()
resource_name = 'keyword'
excludes = ['id', 'keyword_id']
include_resource_uri = False

def alter_list_data_to_serialize(self, request, data_dict):
if isinstance(data_dict, dict):
if 'meta' in data_dict:
# Get rid of the "meta".
del(data_dict['meta'])
# Rename the objects.
data_dict['keyword'] = copy.copy(data_dict['objects'])
del(data_dict['objects'])
return data_dict

Can someone explain the relationship to me in creating such a
hierarchy?

in the line tweets = fields.ToManyField(timelineResource, 'tweets',
full=True)

it means that timelineResource is a child of Keyword right? and
"tweets" would be the column name in timeline table or just a generic
name?

or must i map a matching column that appears in both tables (keyword,
timeline)?

Thank you

--
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.

Re: admin list_filter: limit choices to model values?

In 1.4/trunk, looks like filterspec.py gets replaced by filters.py (as part of adding the ability to filter a list_filter), so we'll just sit tight and wait for 1.4 to be released (rather than have to go  back and remove the defunct filterspec code).

— John

--
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/-/fHJwHJZDaZMJ.
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.

Re: I need help with Python Tools for Visual Studio 2010 and Django

I have never heard of Guess Additions thanks for the tip!

Right now I am going to remove my Ubuntu installation and re-install to give it more RAM and Video memory as well as install guest Additions!

Thanks,

JJ

--
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/-/Zd1wCdtXBgMJ.
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.

Re: Routing to database based on user

I forgot one thing: be cautious with transactions. The transaction
middleware will start a transaction only on 'default' alias. So, you
will probably need to use the transactions.commint_on_success /
commit_manually with the using parameter to make this work reliably.
Or write your own transaction middleware. If you need multidb-spanning
transactions you are in trouble. Or, at least if you need two phase
commit...

- Anssi

On Jan 31, 12:45 am, akaariai <akaar...@gmail.com> wrote:
> On Jan 31, 12:01 am, Tom Eastman <t...@catalyst.net.nz> wrote:
>
>
>
>
>
>
>
>
>
> > Hey guys,
>
> > I'm writing a django project that will require me to route queries to
> > certain large databases based on who the logged in user is.
>
> > So all the tables for django.contrib.auth and session and stuff will be
> > in the 'central' database, as well as a table that maps users to which
> > database they need to use for the main app.
>
> > Can you help me come up with a way of routing database queries this way
> > using a Django database router?
>
> > At the start of the view could I take the logged in user from
> > request.user or wherever it is, and some how provide that variable to my
> > database router for the rest of the request?
>
> > All suggestions welcome.
>
> I assume that settings.DATABASES have all the needed per-user
> databases defined.
>
> I think the best solution forward is to use threading.local to store
> the request.user. So, something like this should work:
>   - have a middleware that stores the request.user in threading.local
>   - database routers just fetch the request.user from the
> threading.local storage.
>
> You could also play with the connections dictionary, something like
> this should work in 1.4:
>
> Have a special database alias 'per_user_db'. Assuming alias 'thedb2'
> is the correct database to use for the user, you would then in a
> middleware do this:
> django.db.connections['per_user_db'] = django.db.connections['thedb2']
> This should work in the upcoming 1.4, but in 1.3 you will get problems
> due to threading.
>
> Now, you will just always route your queries to 'per_user_db'.
>
> For example:
> SomeModel.objects.create(field1=val1, ...)
> connections['default'] = connections['other']
> print SomeModel.objects.all()
> will print an empty list, but if you comment out the assignment, you
> will see the just created object in the DB.
>
> As said, the above should work correctly in multithreaded environment
> only in the upcoming 1.4. In 1.3 the connections assignment will be
> global, and you will get weird errors! Note that I haven't actually
> tested this in multithreaded environment.
>
>  - 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Re: Routing to database based on user

On Jan 31, 12:01 am, Tom Eastman <t...@catalyst.net.nz> wrote:
> Hey guys,
>
> I'm writing a django project that will require me to route queries to
> certain large databases based on who the logged in user is.
>
> So all the tables for django.contrib.auth and session and stuff will be
> in the 'central' database, as well as a table that maps users to which
> database they need to use for the main app.
>
> Can you help me come up with a way of routing database queries this way
> using a Django database router?
>
> At the start of the view could I take the logged in user from
> request.user or wherever it is, and some how provide that variable to my
> database router for the rest of the request?
>
> All suggestions welcome.

I assume that settings.DATABASES have all the needed per-user
databases defined.

I think the best solution forward is to use threading.local to store
the request.user. So, something like this should work:
- have a middleware that stores the request.user in threading.local
- database routers just fetch the request.user from the
threading.local storage.

You could also play with the connections dictionary, something like
this should work in 1.4:

Have a special database alias 'per_user_db'. Assuming alias 'thedb2'
is the correct database to use for the user, you would then in a
middleware do this:
django.db.connections['per_user_db'] = django.db.connections['thedb2']
This should work in the upcoming 1.4, but in 1.3 you will get problems
due to threading.

Now, you will just always route your queries to 'per_user_db'.

For example:
SomeModel.objects.create(field1=val1, ...)
connections['default'] = connections['other']
print SomeModel.objects.all()
will print an empty list, but if you comment out the assignment, you
will see the just created object in the DB.

As said, the above should work correctly in multithreaded environment
only in the upcoming 1.4. In 1.3 the connections assignment will be
global, and you will get weird errors! Note that I haven't actually
tested this in multithreaded environment.

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

Proper way of building model classes in app using 2 databases

Hi,

I'm writting an app which uses 2 databases and I'm wondering how I
should build model classes for tables from second database (which I
only use to read data).

I have a models.py module in my app's package where I defined all the
model classes I needed. I also defined there model classes from second
database but I added "managed = False" meta option to them because I
don't want syncdb to create or reset them. The problem appears when I
do datadump. I got an error telling that a relation "xxx" does not
exists, where "xxx" is relation from second database marked with
"managed = False".

The problem disappears when I create a separate package for model
classes from second database (without adding it to installed apps).
I'd like to ask if solving that problem in such way i the right way?

--
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.