Re: Calling out for Help!
Well, the "python manage.py runserver" command returned a screen full of errors. What would be the appropriate way to post that? I don't want to burn anyone's special eyes. And since we are using Apache, I'm going to say we are also using wsgi. > Well, the first thing to see when deploying a django project is the > settings.py file. Here you'll see the database information. > > Then the second step will be testing it (with the command python > manage.py runserver, it should start the development server, NOT for > using in production). > > The last thing will see the Apache configuration, and it'll depend if > you're using wsgi or fcgi... More information > here:http://docs.djangoproject.com/en/dev/howto/deployment/http://www.djangobook.com/en/beta/chapter21/ > > Hope it isn't that difficult, you can see the configs from the old > server, right? > > Good luck! > Andres- Hide quoted text - > > - Show quoted text - -- 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: Calling out for Help!
I can't let it go.. the whole "ask a question" and "the return key is your friend" thing. I thought I was writing an intro blerb to the moderators... anyway, it was in a little web form box and I just kept typing. I didn't realize it was going to end up as a post. If I wanted sarcasm I'd start a conversion with my employer. On Feb 8, 12:20 pm, Andres Lucena wrote: > On Tue, Feb 8, 2011 at 6:11 PM, Tom Evans wrote: > > On Tue, Feb 8, 2011 at 5:01 PM, Dev@CB wrote: > >> Tom, why are you discouraging me? > > > My intention was not to discourage you; it was to encourage you to ask > > a sensible question in a legible manner. If you take slight at that, > > then I have no problem with not corresponding with you further. > > I think that is always helpful this text: > > http://www.catb.org/~esr/faqs/smart-questions.html > > Specially the part: > > 1. Try to find an answer by searching the archives of the forum you > plan to post to. > 2. Try to find an answer by searching the Web. > 3. Try to find an answer by reading the manual. > 4. Try to find an answer by reading a FAQ. > 5. Try to find an answer by inspection or experimentation. > 6. Try to find an answer by asking a skilled friend. > 7. If you're a programmer, try to find an answer by reading the source code. > > And the return key is your friend ;) -- 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: Calling out for Help!
Andres, Thank you for your kind, helpful reply. Heading to lunch now, more django later! Thank you again, Justin -- 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: Calling out for Help!
Tom, why are you discouraging me? -- 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.
Calling out for Help!
Hello. I hope someone is maybe having a slow day and can spend a little time with me. Here's the whole story: Several months ago, our company started a django project. This project was headed by one man. Well, as of early January, he is no longer with the company. Now, we, the survivors, have the task of completing the project. Oh, little more background: Everything was set up on an Amazon cloud server. I think originally the project seemed simple enough to be run on a “small cloud”. So, here is where we are at now: This one report actually turned out to be a monster and took several hours to run. That’s not good; that report needs to run in a few minutes with more data being processed. So, I created a “large cloud” (with AutoScaling, a feature not available to small clouds), installed Apache, PHP, MySQL, Python, and Django. I used SCP to copy the data from one server to another. Now, I need to align the configuration files to make it all work on the new server. This is where I need help. The small server was a Ubuntu distro and the large is a SUSE Enterprise 64-bit version, and some default paths and different things are not the same. I mentioned I did all the setup myself to give you the idea that I’m linux-savvy, but in truth, that was all a learning experience. I’m learning fast, but my supervisor wants all this done last week. Can anyone help me? At least give me a good push in the right directions, so that I can take off on my own again. Please? -- 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: Switching from soc2009/multidb to trunk; cross db foreign keys
> Apologies for taking so long to get back to you on this - the silly > season has been consuming a lot of my time. Silly season indeed :) > I'd go one step further than an attribute - I'd provide a method. I was considering this, but I was thinking about a hacky/internal API for 1.2 instead of doing the full implementation that I read was being thrown around :) I suppose it is an easy logical extention. > The > default implementation would essentially be: > > def db_from_related_object(self, instance): > return instance._state.db I'm not familiar with ._state and not sure if you're referencing existing attributes on the manager, but I can see what you're getting at. > The related manager would then use the following: > > using = rel_mgr.db_for_source(instance) > if getattr(rel_mgr, 'use_for_related_fields', False): > rel_obj = rel_mgr.using(using).get(**params) > else: > rel_obj = QuerySet(self.field.rel.to).using(using).get(**params) Yes, exactly. I didn't want to jump in much further than I had to, so I haven't actually patched this (monkey patching is fun, heh) as a quick guess is it needs to be done in another place for M2M. I have merely passing familiarity with this stuff, until the other day I wasn't even aware of these 'magic' descriptors in django. > In your use case, you would override this method on the AdSalesManager: > > def db_from_related_object(self, instance): > return 'adsales' > > so no matter where the request for an AdSales object comes from, the > adsales database will be used. If you wanted to implement a sharding > strategy, you could put in more complex logic based on instance. Agreed. > Some sort of configuration in this direction will obviously be > required in the long term, and it's arguably a bug in the current > implementation - we need to expose a way to control the using() > arrangements for related fields, and we don't currently do so. This does seem to be the biggest issue at the moment. > Given > that this is a fairly glaring hole in the API, I'm certainly open to > providing a fix in the 1.2 timeframe. I'm not too familiar with when exactly this timeframe is - if it's still a bit away and this doesn't count as a 'feature' (i.e., I have maybe a week or so) I might try writing up a patch. > My only question is whether we should try to make this public API for > this release. Without an understanding of exactly how soon you want 1.2 out, and as I'm not exactly the best unit tester... ;) I think keeping this an internal API might be best for now until someone a bit more knowledgeable about the internal plumbing than me weighs in on these ideas. > I'm slightly hesitant to introduce API without a > complete understanding of exactly how multi-db will be used in the > field. For example, you've highlighted a problem on retrieval, but > there will be an analogous problem on assignment - in the current > implementation, book.author = user will force user onto the same > database as book, (or force book onto the same database as user if > book hasn't been db-assigned). This is obviously wrong for the use > case your provide. I totally forgot about assignment! In the monkeypatched code I posted before, assignment (seemingly) works by segregating the models across DB (that is, keeping all instances of a model on a single db) by basically making the default implementation return 'default' instead of keeping the 'from whence it came' strategy for related models. We probably should name / detail these partitioning strategies so we can discuss them easier: 1. Follow Original DB: Always resolve relations by staying on the same DB as the source relation 2. Force Model DB: Always resolve relations by using The code I posted above sticks with option 2, and treats an un- dbassigned model as assigned to 'default'. > So, my suggestion would be to introduce an API to solve this problem, > but prefix the methods we add with underscores to highlight that this > is internal API for now. Come 1.3, we can then change these API > (either dropping the underscores, or replacing the underscore methods > with an entirely new technique) without breaking backwards > compatibility. Anyone using the internal API should be aware (because > of the underscore) that there may be some migration work required to > move from 1.2->1.3. Agreed. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Switching from soc2009/multidb to trunk; cross db foreign keys
Putting the following code somewhere after settings.py is imported (a new app called 'startup' in __init__.py, with 'startup' added first in INSTALLED_APPS is a good place), will allow you to lock models to databases via a manager's forced_using attribute. This definitely not 'the best way', as monkey patching is a little nasty. However, I'm not sure this would be accepted as a patch (when formulated as such), and this works for me, so i'm just sharing it for whoever needs it. I haven't seen any bugs, so if you use it and find any let me know. Thanks again to Alex for making the multidb branch. -CB from django.db import models def hijack_for_partitioning(): """This class enables you to add a forced_using = 'db_name' to a manager, which will lock queries and saves for that model to that particular db. In addition, if this is /not/ specified on a custom manager, it will lock every model to the 'default' db. """ _real_save = models.Model.save def save(self, *args, **kwargs): kwargs['using'] = type(self).objects.forced_using #Makes sure instances are saved in the proper place _real_save(self, *args, **kwargs) models.Model.save = save _real_get_query_set = models.Manager.get_query_set def get_query_set(self): qs = _real_get_query_set(self) if hasattr(self, 'forced_using'): qs = qs.using(self.forced_using) qs._real_using = qs.using qs.using = lambda new_using: qs._real_using(qs._db) #Disable changing db with .using() - required because related manager tries to set .using after we return the qs return qs models.Manager.get_query_set = get_query_set models.Manager.forced_using = 'default' models.Manager.use_for_related_fields = True hijack_for_partitioning() -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Switching from soc2009/multidb to trunk; cross db foreign keys
> Hrm, it's clear that the current implementation is probably overly > aggressive in changing the DB I definitely agree here. It just seems like a useful working solution for 'now', clearly somethign a bit more elegant would be needed to make it into Django's core. > That being said in > your case it might make sense for using() to be a no-op, since by > definition your manager is supposed to work with a specific DB. Yes, and I think this is a somewhat common use case. If we could convince the related managers not to call .using() on the returned queryset (perhaps by means of a class attribute on the manager just like use_for_related_fields), we can drop the override of the .using() method on the queryset. Do you think this flag addition is small enough for a bugfix / feature in the 1.2 timeframe? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Switching from soc2009/multidb to trunk; cross db foreign keys
*Oops, sorry about the refrences to 'AdSalesModel' and setting using='adsales' - you can see where I'm using these ideas :) Change them to PartitionedModel and self.objects.forced_using respectively. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Switching from soc2009/multidb to trunk; cross db foreign keys
So I did some basic poking around with managers, etc.
I noticed what 'may be' a 3 part solution to keep a model on one and
only one db:
First, we should modify the initial queryset to use our preferred db.
We can do this by adding a custom manager, with an overridden
get_query_set():
class PartionedManager(models.Manager):
use_for_related_fields = True #Forces this manager to be used
during related lookups
def __init__(self, *args, **kwargs):
self.forced_using = kwargs.pop('using', 'default')
super(PartionedManager, self).__init__(*args, **kwargs)
def get_query_set(self):
return super(PartionedManager, self).get_query_set().using
(self.forced_using)
However, this doesn't solve the ability to .save() into another db, so
lets create an abstract model our real stuff can inherit from:
class PartitionedModel(models.Model):
objects = PartitionedManager(using='aux')
def save(self, *args, **kwargs):
kwargs['using'] = 'adsales' #Makes sure instances are saved in
the proper place
super(AdSalesModel, self).save(*args, **kwargs)
class Meta:
abstract = True
class ConcreteModel(PartitionedModel):
name = models.CharField(max_length=255)
class SomeModelOnTheMainDB(models.Model):
name = models.CharField(max_length=255)
concrete = models.ForeignKey(ConcreteModel)
So far so good. However, relations still throw an error that models
can't be found. The reason for this is:
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L262
The related code instantiates the manager, and then immediately
changes it's db with a .using() clause to wherever the original model
came from (e.g., another db). Since we want to force this, we have two
options:
1) get a django patch that can find another class attribute on the
manager and optionally not apply that using(), or apply a forced using
(), or
2) hack it!:
class PartionedManager(models.Manager):
use_for_related_fields = True #Forces this manager to be used
during related lookups
def __init__(self, *args, **kwargs):
self.forced_using = kwargs.pop('using', 'default')
super(PartionedManager, self).__init__(*args, **kwargs)
def get_query_set(self):
qs = super(PartionedManager, self).get_query_set().using
(self.forced_using)
qs._real_using = qs.using
qs.using = lambda new_using: qs._real_using(qs._db) #Disable
changing db with .using() - required because related manager tries to
set .using after we return the qs
return qs
class PartitionedModel(models.Model):
objects = PartitionedManager(using='aux')
def save(self, *args, **kwargs):
kwargs['using'] = 'adsales' #Makes sure instances are saved in
the proper place
super(AdSalesModel, self).save(*args, **kwargs)
class Meta:
abstract = True
class ConcreteModel(PartitionedModel):
name = models.CharField(max_length=255)
ConcreteModel here is now tied to a db. I'm testing this code in
production, and was wondering what everyone thought?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: Switching from soc2009/multidb to trunk; cross db foreign keys
> In short, you can't (or shouldn't). > > What you're asking the database to do is keep a foreign key value that > is not valid on the database on which it is stored. Yes, this is true. > The multi-db branch had checks for this sort of referential integrity > until just before the merge; however, these checks were relaxed just > prior to commit in order to allow for multi-db to support master-slave > partitioning - in these situations, a model will appear to be on a > different database alias, but won't be a referential integrity failure > since it is actually the same database. Yeah, i watched these checks go up and then drop out. > We may also need to look at ways of storing > cross-database foreign keys to accommodate the sort of use case that > you describe. What about creating a new set of ForeignKey fields that don't actually do any real foreign key checking? Maybe CrossDBForeignKey, or RelaxedKey? I understand if this is off the timetable for 1.2 (as I can see the dev group is getting ready for freeze, etc) but if I wanted to develop this route, do you have any pointers? Might I be able to simply subclass ForeignKey (or one of it's bases, etc), and more or less lie about the constraint being fulfilled, tell the DB that this is just an int (like IntegerField), and then convince the Query internals to ask for my data seperately (making it not eligible for select_related, for example)? Either way, i'm going to look into this use case myself and try to make it work (in a hopefully not /too/ hacky way) . If you or anyone else has any pointers, please let me know. Thanks, -CB -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Switching from soc2009/multidb to trunk; cross db foreign keys
Hello.
I've been developing on the multdb branch for awhile now (most recent
version just before the dropping of the 'using' meta attribute), and
everything has been going well. Recently though, with multidb landing
in the trunk, I wanted to switch over to the trunk.
I have a 'partitioning' scheme somewhat like this:
db_extra
class Building(models.Model):
area = models.ForeignKey('area')
...etc
default
class Area(models.Model):
...etc
And in db_extra, i've defined a custom manager that overrides
get_query_set(), returning .using('db_extra') as per the svn docs.
Now, my admin changelist includes the 'area' foreign key field on
Building. In the multidb branch, all was fine - the admin 'correctly'
retrived the foreign key id number from the db_extra db, and looked it
up locally in default. In the trunk now, I get a TemplateSyntaxError
indicating that the specified Area does not exist.
Clearly, it is now looking to the db_extra db for the related area
instead of looking to default.
Am I doing this correctly? How can I inform django to lookup the
foreign key in this db?
Thanks for any help.
-CB
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
