Re: Python/Django programmers needed (telecommute)...

[Jason McVetta]

My qualifications are a great match for this role. I'm available FT on-site
for $300/hr. Rate is negotiable for remote or less than full-time work.





-- sent from my robot
On Dec 4, 2014 3:55 PM, "Fred Stluka"  wrote:

>  Django programmers,
>
> Interested in a telecommute position for $80-100K/year?
>
> I just forwarded this one to my "Job Wanted" and "Consultants"
> mailing lists.  See email appended below.
>
> Also, for anyone local to Philadelphia PA, I expect to be
> recruiting onto my own team in about a month or so.
> Telecommute with weekly status meetings in Radnor PA,
> and ad-hoc local co-working sessions with the dev team.
>
> Interested in either one, please let me know.
>
> --Fred
> --
> Fred Stluka -- mailto:f...@bristle.com  --
> http://bristle.com/~fred/
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
> Open Source: Without walls and fences, we need no Windows or Gates.
> --
>
>
>  Forwarded Message   Subject: Python/Django programmer
> needed (telecommute)...  Date: Thu, 4 Dec 2014 18:46:36 -0500 (EST)  From:
> f...@bristle.com  To: f...@bristle.com
>
> Job seekers and Consultants,
>
> I'm hesitant to send this one out because I'm going to be trying
> to recruit such people onto my own team in another month or so,
> and I'd hate to lose the best of you to this guy, but...
>
> It seems like a good offer.  The salary is pretty low, but the
> rest of the job description sounds really appealing, and maybe
> the right guy can get them to double the salary to get it up to
> market rate.  So it would be selfish of me to not at least tell
> you about it.
>
> - Senior Python/Django programmer
> - Educational software product company, start-up, college portal
>   product, successful at one college and rolling it out across the
>   country.
> - Skills:
>   - Python/Django
>   - FOSS
>   - Agile, demonstrative excellence, code quality, peer code reviews
>   - Proficient and proactive communicator both written and oral
>   - Python MVC frameworks: Django, Pyramid, Flask
>   - Memcached, Celery
>   - TDD, PyLint, Nose, Twill, Mechanize, Selenium
>   - Jenkins, Bamboo
>   - REST, Django-Rest-Framework, Tastypie, Web services
>   - Django's ORM, SQLAlchemy, MySQL, PostgreSQL, MongoDB, DynamoDB
>   - JSON, HTML5
>   - JavaScript, jQuery, Ajax
>   - RWD (Responsive Web Design), Bootstrap
>   - Cloud, AWS S3, EC2, CloudFront, Route53, CloudFormation
>   - Git
>   - Redis, MongoDB
>   - Salt, Ansible
>   - DevOps
>   - Node.JS
>   - Ember.js, Backbone.js
>   - ElasticSearch, Solr, Haystack
> - Consultant becoming FTE (right to hire)
> - 6+ months
> - $80-100K/year
> - Telecommute with 1-2 weeks/year onsite in Indianapolis
>
> Interested?  Let me know.
>
> --Fred
> -
> Fred Stluka -- mailto:f...@bristle.com  -- 
> http://bristle.com/~fred/
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
> Open Source: Without walls and fences, we need no Windows or Gates.
> -
>
> Fred,
>
> Thank you for your detailed response and good luck with your project.
>
> I'll attempt to answer your questions and anyone interested can
> contact me for more details -- thanks!
>
> Some questions I always ask (some of which were answered
> in your attached job description):
> - Brief description of the company, what it does, what the
>work environment is like, etc?
>
> Educational software product company, start-up, college portal
> product that was successful at one college and rolling it out
> across the country.
>
> - Brief description of the responsibilities of the position you
>are trying to fill?
>
> See JD, mid-senior level, some mentoring/coaching of junior
> developers
>
> - Technologies used and skills needed?
>
> See JD
>
> - Consultant or FTE?
>
> Consultant at first under my firm, then fulltime with my client
>
> - Full time or part time?
>
> Fulltime
>
> - How long is the initial contract?
>
> 6-month contract to hire, more or less based on client preference
>
> - How long is the project likely to run?
>
> Fulltime position after contract
>
> - Approx salary or hourly rate offered?
>
> Salary in the $80-100K for fulltime, some leeway higher if needed,
> salary converted to hourly for contract period
>
> - Location (Philly, western suburbs, Wilmington, telecommute, etc.)?
>
> Telecommuting, client is located in Indy, occasional travel to
> Indy required but should not exceed 1-2 weeks annually, 1-2 weeks
> onsite at start of contract to meet team/etc.
>
> 
>
> Wow!  That is a REALLY good match for my skills and interests!
>
> I particularly like these aspects (almost everything you described
> -- my friends would say you wrote the job description for me
> personally

Re: Unexpected logouts with latest from svn

[Jason McVetta]

On Nov 8, 2007 9:04 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:

> We're now at r6652 on trunk. So if that doesn't work for you, pick a
> revision halfway betewen 6300 and 6652, update to that and see if the
> problem appears. If so, go back halfway, otherwise go forwards halfway.
> Keep bisecting your way through revisions until you find the commit that
> is the problem. It's a maximum of 9 checkouts you'll have to do (and
> probably a maximum of 8, since revision numbers include commits to gis,
> newforms-admin and queryset-refactor branches).
>

Using this process I have isolated the revision where the bug began:
r6333.  A big change to the sessions middleware was made in that revision,
to support saving session data in file or cache as well as database.  I
haven't yet figured out just what is wrong; but a quick test shows the bug
occurs independent of which session backend is used.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Solution: using Many-to-Many horizontal interface outside of admin

[Jason McVetta]

A number of people, myself included, have asked this list how the admin
interface's slick javascript many-to-many widget can be used in templates
outside admin.  None of the answers given solved the issue for me, but they
did point me in the right direction.  After a day of reading the source, I
was able to get the widget to work with my templates.

Here's how I got it working:

   1. Get the right javascripts imported.  Two script files, "core.js"
   and "SelectFilter2.js", are needed.  Additionally, you must include
   the jsi18n view generated by admin interface; by default its url is
   "/admin/jsi18n".

   
   
   

   2. Decorate your form field with the "vSelectMultipleField" class
   attribute.  For example, if you had created a form called "form" from your
   model, and the M2M field was called "foo", you would put this in your view:

   form.fields['foo'].widget.attrs['class'] = 'vSelectMultipleField'

   3. Include javascript in your template to initialize the widget.  For
   our "foo" example, you would insert this line somewhere after {{
   form.foo }}:

   addEvent(window, "load", function(e) {
   SelectFilter.init("id_tags", "tags", 0, "/media/"); });

   In the admin interface, inserting this code is handled by a template
   tag called "filter_interface_script_maybe".  That tag has admin-specific
   logic, but one could easily write a similar tag for one's own templates.


I hope that is helpful.





On 6/13/07, Jason McVetta <[EMAIL PROTECTED]> wrote:
>
> Forgive this question if the answer is overly obvious; but I have not yet
> figured it out.  I want to use the horizontal M2M widget from the admin
> interface in my own template.  The model looks like something this:
>
> class Foo(models.Model):
> bars = models.ManyToManyField(Bar, filter_interface=models.HORIZONTAL)
>
> My views.py looks something like this:
>
> def myView(request, object_id):
>foo = Foo.objects.filter(id=object_id)[0]
>FooForm = form_for_instance(foo)
>form = FooForm()
>rc = template.RequestContext(request)
>return render_to_response('path/to/mytemplate.html', {'form': form},
> rc)
>
> And my template includes a line like:
>
> Bars: {{ form.bars }}
>
> While the model alone is sufficient to produce a horizontal filter in the
> admin interface, in my template all it displays is a basic HTML select
> multiple list.
>
> I suspect the answer lies in decorating the widget rendered by {{
> form.bars }} with a class or id so the Javascript knows to beautify it,
> but I am not sure how to do so.
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

using Many-to-Many horizontal interface outside of admin

[Jason McVetta]

Forgive this question if the answer is overly obvious; but I have not yet
figured it out.  I want to use the horizontal M2M widget from the admin
interface in my own template.  The model looks like something this:

class Foo(models.Model):
bars = models.ManyToManyField(Bar, filter_interface=models.HORIZONTAL)

My views.py looks something like this:

def myView(request, object_id):
   foo = Foo.objects.filter(id=object_id)[0]
   FooForm = form_for_instance(foo)
   form = FooForm()
   rc = template.RequestContext(request)
   return render_to_response('path/to/mytemplate.html', {'form': form}, rc)

And my template includes a line like:

Bars: {{ form.bars }}

While the model alone is sufficient to produce a horizontal filter in the
admin interface, in my template all it displays is a basic HTML select
multiple list.

I suspect the answer lies in decorating the widget rendered by {{
form.bars}} with a class or id so the Javascript knows to beautify it,
but I am not
sure how to do so.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: databrowse and @login_required

[Jason McVetta]

On 5/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Or you could subclass DatabrowseSite -- in your own code somewhere; no
> need to even modify the source -- and override the root() method to do
> an auth-check first and then call DatabrowseSite.root(). Then you
> replace databrowse.sites with an instance of your subclass.



Didn't even need to subclass it.  Instead, I took what seemed the
least-invasive route, and made my urls.py look like this:

from django.conf.urls.defaults import *
from django.http import HttpResponseRedirect
from django.contrib import databrowse

def authorized_databrowse(request, url):
if request.user.is_authenticated():
return databrowse.site.root(request, url)
else:
return HttpResponseRedirect('/login/?next=%s' % request.path)

urlpatterns = patterns('',
(r'^databrowse/(.*)', authorized_databrowse),
(r'^login/$', 'django.contrib.auth.views.login'),
...
)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

databrowse and @login_required

[Jason McVetta]

What is the right way to require a user be authenticated when using the
databrowse module?  I tried adding @login_required decorators to both
functions in databrowse.views, but that did not work -- it appears
databrowse does not presently use its views.py.  I also tried decorating
databrowse.DatabrowseSite.root with @login_required, but it threw this
exception:

Traceback (most recent call last):
File "c:\opt\Python25\Lib\site-packages\django\core\handlers\base.py" in
get_response
  77. response = callback(request, *callback_args, **callback_kwargs)
File
"c:\opt\Python25\lib\site-packages\django\contrib\databrowse_jm\sites.py" in
root
  120. return self.index(request)
File "c:\opt\Python25\Lib\site-packages\django\contrib\auth\decorators.py"
in _checklogin
  16. if test_func(request.user):

  AttributeError at /databrowse/
  'DatabrowseSite' object has no attribute 'user'

Can someone point me in the right direction?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: OT: Resources for converting MySQL data to PostgreSQL for Django

[Jason McVetta]

Check out Kettle (aka Pentaho Data Integration) from
http://kettle.pentaho.org.  It's a heavy-weight tool, but it has a fairly
intuitive GUI and decent documentation.  It's Open, of course, and very
multi-platform (I personally use it on Windoze, Solaris, and occasionally
Linux).

The function you want is called "Copy Tables Wizard".  Just used that last
week to migrate one of my Django apps from MySQL to Postgres.  It's pretty
straightforward and hassle-free.





On 5/26/07, Hancock, David (DHANCOCK) <[EMAIL PROTECTED]> wrote:
>
>  We are strongly considering migrating from MySQL to PostgreSQL, but there
> seem to be enough differences between the two that I'm pulling my hair out.
> I know this is somewhat off-topic, but has anybody got some resources for
> the conversion process?
>
> I'd love it to be as simple as a dump-and-restore, but so far, no silver
> bullet has emerged. Things I've tried:
>
> mysqldump --compatible=postgresql # not so compatible
> dump-db.py from djangosnippets.org # many data differences
> hand-editing dumped SQL # too much work, nonexistent foreign key
> values
> manage.py dumpdata # chokes on Decimal(0.00) datatype, not sure how to
> load output anyway
>
> Thanks in advance, and
> Cheers!
> --
> David Hancock | [EMAIL PROTECTED]
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Using Django outside of Django

[Jason McVetta]

On 5/1/07, Michael K <[EMAIL PROTECTED]> wrote:
>
> Joe's post is on the money.  You shouldn't need to use the shell at
> all, but can directly import django's pieces directly in another
> script (such as your streamer.py).


While it is entirely possible to use Django modules in scripts, you may
encounter some strange errors with ManyToMany relations.  These errors are
caused by a known, but very difficult, bug.  If you see "cannot resolve
keyword" exceptions when running stand-alone scripts, check out the "
django-m2m-kludge.py"
work-around attached to bug 1796 
.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Many to Many relations - DB errors

[Jason McVetta]

On 5/1/07, MattW <[EMAIL PROTECTED]> wrote:
>
> I'm having problems with the Many-to-Many relations in my model.


You'll need to include the model.py code, so people can see what is going
on.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Recommended Editor/IDE

[Jason McVetta]

Another vote for Eclipse + PyDev + Subclipse.  Not mentioned by the others:
it's easy to run the Django development server inside the PyDev debugger.


On 4/29/07, Sat <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> Is there a recommended editor or IDE for windows that is django savvy?
> Ideally, I am looking for one that handles bundles/snippets for django
> as well as syntax highlighting and code completion for django and
> python.
>
> Thanks in advance for your help.
>
> Sat
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: audit trail support

[Jason McVetta]

Here is my current thinking:

   - No changes to main model tables
   - Designate a model to be audited by including inner class "Audit"
   - One shadow table per audited model
   - Generate shadow tables for all audited models on post_syncdb
   - Only write to one DB, until multi-db support is completed for Django
   - Write audit record on post_save, w/ flag in one column indicating it
   was a post_save write
   - At the user's option (set by attribute on Audit inner class), also
   write an audit record on pre_save, w/ appropriate flag
   - Maybe include a cron script to discard old audit records, based on
   age or total number of records

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Primary key field can be empty

[Jason McVetta]

On 4/25/07, Ramiro Morales <[EMAIL PROTECTED]> wrote:
>
> Try adding blank=False explicitely because it works
> at the admin UI level so it doesn't know about database
> primary keys and such.


I have experienced the same bug.  I have a model that sets its primary key
like this:
CharField(blank=False, maxlength=8, primary_key=True)

When adding an instance of that model in the admin interface, I am indeed
able to save the instance with no primary key defined.  Which then makes it
impossible to delete that instance using the admin interface.  This happens
both in 0.96 and svn.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Cannot resolve keyword into field

[Jason McVetta]

On 4/24/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
>
> I've posted a modified script of what I'm using internally for a
> script that had encountered this problem. [0]  I'll be curious to hear
> if it this helps you out at all.


Ben, thank you very much for the script -- it fixed my problem!

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Cannot resolve keyword into field

[Jason McVetta]

On 4/24/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> I now have to sit down and work out a proper solution. That will take
> time and I don't have that at the moment because I have other
> priorities. Of course, anybody else should feel free to dive in and
> write a fix, too, but that hasn't happened so far.


I would be happy to write a fix; but unfortunately, I do not yet understand
the bug well enough to do so.


Until then, anybody being bitten by the problem might want to try Ben
> Slavin's workaround patch in #1796.


Ben posted patches for the management shell and for mod_python.  The case
where I am experiencing this bug is running a script from the command line
(or from cron).  I tried including his work around code
# XXX: (Temporary) workaround for ticket #1796: force early loading of all
# models from installed apps.
from django.db.models.loading import get_models
loaded_models = get_models()
at the beginning of my script, but it did not help the problem.


This is a bit of an oversimplification, since it occurs more with
> reverse relationships and it's not "any time", it's only sometimes and
> depends on the code (model names, etc), OS, installation details and
> which deployment method you're running under. Typically the reverse to
> what you describe occurs: a problem like this is more likely to show up
> in the admin interface or when running under mod_python.


Interesting -- maybe it's because I am running from svn rather than a
release, but I personally have not experienced this bug in the admin
interface.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: audit trail support

[Jason McVetta]

On 4/24/07, robin_percy <[EMAIL PROTECTED]> wrote:
>
> What about doing both?  Write a pre_save record indicating the
> operation about to be attempted.  And a post_save indicating the
> success of the operation, using a unique identifier to identify the
> pair.  Then if the post_save gets out of sync, you have a record of
> transactions that may be at fault.


I was considering something like that.  But would it require two additional
tables for every audited model?  Or I could have just one table for writing
post_save confirmation -- but how to create an identifier that is unique
across several tables?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: audit trail support

[Jason McVetta]

On 4/23/07, David Larlet <[EMAIL PROTECTED]> wrote:
>
> It's a bit ugly to declare instance hidden variables (pre) but we need to
> be
> sure that the save/delete is effective (post) before logging it.
>

It's not beautiful, perhaps, but I may end up doing something very similar.
However, one requirement of my project is that the audit tables not require
UPDATE or DELETE permission.  Which begs the question, if I write my audit
record on the pre_save signal, how do I record the success or failure of the
save() operation?

Alternatively, I could write the audit record on post_save.  Although I
can't think off the top of my head of an example where this would get out of
sync with the main table, something about it feels risky.  But I will have
to think about this one some more.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: audit trail support

[Jason McVetta]

On 4/21/07, Tim Chase <[EMAIL PROTECTED]> wrote:
>
> Todd Schraml authored a good article in Dr. Dobb's Journal
> (http://www.ddj.com/dept/database/184406340) titled _Table
> Patterns & Changing Data_ where he discusses five patterns for
> keeping historical data, and the requirements that would lead to
> choosing one pattern over another.



Thanks for the article, Tim -- it looks informative.  :)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Cannot resolve keyword into field

[Jason McVetta]

On 4/21/07, Ramashish Baranwal <[EMAIL PROTECTED]> wrote:
>
>   TypeError: Cannot resolve keyword 'book' into field



This is a long-standing, well-known bug that apparently no one (including
me) knows how to fix.

Any time one defines a ManyToMany relationship, then calls all() on that
relationship from a script, a "cannot resolve keyword into field" error
results.  The problem involves some deep voodoo about how and when modules
are imported, which is why it occurs only in scripts but not in the admin
interface or the manage.py shell.  If you google around the django-users
archives and bug tickets, you'll see some (imho truly hideous) hacks for
working around it by mangling your import statements.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: audit trail support

[Jason McVetta]

On 4/20/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> In your descriptions below, you remove the ability for a developer to
> use manual primary keys, by the sound of it, since one of your special
> fields wants to be a single-column primary key. That's not invisible.


Does Django currently allow use of composite primary keys?  If so, I wasn't
aware. Either way, the only restriction I would want to put on the keying of
the tables is that they not use one of the reserved column names (e.g.
"record_is_deleted").

I wouldn't go as far as to say "significantly heavier" without a lot of
> profiling under operational loads. Using sensible table indexing,
> including functional indexes on databases that have them, should make
> that query perform reasonably well for many cases (gut feel based on a
> bit of experience with large databases).


Fair enough.  It definitely makes the queries more complex, since they must
always include statements to select the current, non-deleted record.  But
that doesn't mean the performance would be unacceptable.

A real drawback of this method that you don't mention is that adding
> audit support requires changing the database table. So you can't add it
> to standard (shipped with Django) or third-party modules easily.


Yes, I would prefer my solution be drop-in compatible with both standard
Django and typical third-party modules.  Which does argue against modifying
the model tables.

>  2. The audit table, as described above, is written seperately
> > from the working table used for reads.  It would be most
>
> You still have to change the main table for the model, though, right?
> Otherwise you won't be able to have more than one tuple of data for each
> model (due to constraint violations). This was a problem that existed in
> the design of the FullHistory work as well: how to store arbitrary bits
> of changed information without having to alter existing tables.


No, I will not need to change the main table for the model.  But as you
point out, the audit table's schema cannot simply be main table +
record-keeping columns.  Instead, its schema must be: main table with
modified contraints + record-keeping columns.

If you could find a way that all the audit-related information was in a
> separate table, I would be tempted to implement it similar to
> ContentTypes -- as a table that is related to the model(s) it governs
> (maybe there is a shadow audit table for each real model table, but
> that's a bit uncool from a database design perspective). The extra table
> join won't really hurt you with today's databases and proper indexing.


Keeping a shadow table for each audit table is looking like the best
solution to me right now.  Granted it does add a little clutter to the table
namespace -- but shadow tables will be created only for models that
explictly ask for them.   Is it worthwhile to make it possible to store the
audit shadow tables in a separate db?

I suspect you will be able to do most of it as a third-party app without
> needing to hack on core. Some monkey patching -- a term I hate because
> it suggests it is wrong somehow, but I'll stick with the common phrase
> -- of the QuerySet class might be necessary (replacing QuerySet with a
> version that understands how to get the "real" row for a model). You
> might be able to get away with subclassing QuerySet in a lot of cases,
> but I'm not sure that will give you everything.


If I am only interested in writing shadow tables to keep history, don't
think I would need to touch QuerySet.  Instead, just define some pre_save
and pre_delete callbacks for the dispatcher.  (And maybe  post_save and
post_delete, to verify that the save/delete had been successful?)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

audit trail support

[Jason McVetta]

I need to add real audit trail and change-notification support to an
existing Django app and to one that is under development.  The best way to
do this, it seems to me, is to add audit support to the Django framework
itself.  My requirements are similar to those named by Paul Childs in his
django-users 
postlast
June:

   - rows, once written, are immutable -- system should be able to
   operate without UPDATE and DELETE privileges on the audit db
   - editing a record creates a new row (with higher version and/or date)
   but does not touch old record
   - deleting a record creates a new row to be created with the
   "record_is_deleted" flag set to true
   - (optional) whenever a new row is written, user must supply a comment
   explaining the change
   - (optional) whenever a new row is written, an email is sent to an
   address specified in the model

To clarify, when I say "row" I mean a literal row in the database; and when
I say "record" I mean the representation of a Django model.  A record will
have many rows associated with it in the audit db, if it has been modified
many times.

Audit trail support would be enabled on a per-model basis, probably by
including an AuditTrail inner class.  That inner class would then be used to
specify audit options.  Beyond including this inner class, and an
to-be-determined method for attaching comments to changes, audit trail
support should be invisible to developers.  Both the existing admin log and
the FullHistory branch are
inadequate for my requirements.

I will be working on this project as part of my Real Job(tm), so devoting
time to it should not be a problem.  However, before I begin coding, I want
the community's input on a few issues.

What is the right way, at DB level, to implement the audit trail?  I had two
ideas:

   1. The table representing a model with AuditTrail enabled will include
   fields such as "record_id", "row_id", "record_version", "record_is_deleted",
   and "row_timestamp".  Row_id will be the primary key for the table, but will
   not be meaningful for identifying a given record.  Record_id and
   record_version will be unique together, and together sufficient for locating
   the current version of a given record.  Reading the current record can be
   accomplished by a query like "SELECT *, max(record_version) FROM table_name
   WHERE record_is_deleted IS FALSE GROUP BY record_id", or a database view
   encapsulating the same query.
   Advantage:  The audit table is guaranteed to be in sync with the
   production data, since they are one and the same
   Disadvantage:  Significantly heavier database load.
   2. The audit table, as described above, is written seperately from the
   working table used for reads.  It would be most useful if the audit table
   could be written to a wholly separate database.  The working table is
   unchanged from today's Django.
   Advantage:  Fairly trivial increase in database load
   Disadvantage:  In the event of an application error, it would be
   possible for the working table and audit table to get out of sync
   3. I am open to better suggestions.


Perhaps the core developers can tell me, will it be possible to do this as a
contrib plugin?  I would, of course, rather do it as a plugin than hack on
the Django core.  But either way, my ultimate goal is to create a high
quality solution that can be included in the main trunk.

Lastly, would it have been more appropriate to post this to
django-developers?



Jason

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: selecting a framework ,

[Jason McVetta]

Django is a great framework for building custom web apps -- but I am not
sure it is the most sensible solution for your needs.  If what you want is
standard ERP functionality, delivered over the web, there is no need for you
to reinvent the wheel.  Quite a few existing open source projects may meet
your needs; check out OpenBravo, Compiere, ERP5, webERP, etc.



On 4/19/07, gops <[EMAIL PROTECTED]> wrote:
>
>
> Hi ,
>
> I want to develop a ERP for very small business ( two - three use +
> customer : normally not more than 10 people using the erp ) , I know a
> little bit of php , but i am interested in django as my platform ,
>
> my question is , is there any such system available which i can look
> at to get some idea , from where to start... ???
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---