Journals and Documents in an accounting application
Luc Saffre
here is a code example that illustrates how I plan to implement journals
in an accounting application. The attached file models.py contains the
details. I saved it (together with an empty __init__.py) in a new
directory "journals" under django/tests/modeltests of my SVN working
copy (which I just updated to revision 10921), then I went to
django/tests and run the command::
python runtests.py --settings=settings_memory -v1 journals
to test it. I'm almost happy, but I get an unexpected result in line 60::
File "L:\snapshot\django\tests\modeltests\journals\models.py", \
line 60, in modeltests.journals.models
Failed example:
INV.lastnum
Expected:
1
Got:
2
I don't understand why INV.lastnum returns 2 and not 1 at this place. If
you see the reason, then please tell me!
Also, I'd be glad to get feedback on my way of solving this particular
problem, and I suggest to add this to the Django tests collection once I
got it working.
Luc
Karen Tracey
Hello,
here is a code example that illustrates how I plan to implement journals
in an accounting application. The attached file models.py contains the
details. I saved it (together with an empty __init__.py) in a new
directory "journals" under django/tests/modeltests of my SVN working
copy (which I just updated to revision 10921), then I went to
django/tests and run the command::
python runtests.py --settings=settings_memory -v1 journals
to test it.
Why are you putting these in among Django's tests? They are your models, so (assuming your app is named 'journals', and you have this models.py file in journals/models.py) you should run the tests via manage.py:
python manage.py test journals
I'm almost happy, but I get an unexpected result in line 60::
(I think you added some lines at the top of the file between getting this result and posting it...the line where this error is reported in the file you have attached is line 72.)
File "L:\snapshot\django\tests\modeltests\journals\models.py", \
line 60, in modeltests.journals.models
Failed example:
INV.lastnum
Expected:
1
Got:
2
I don't understand why INV.lastnum returns 2 and not 1 at this place. If
you see the reason, then please tell me!
Your INV variable is a Journal model instance you created early on in the test. Each time you add a document you do it through calling a method on the instance INV, so its lastnum attribute gets updated. When you delete, however, you delete a document instance. This has code to update the lastnum for the associated Journal in the database, but has no effect on the in-memory Journal instance INV. If you want the instance INV to reflect the latest value in the database you will need to re-fetch it from the database.
Adding:
>>> INV = Journal.objects.get(id='INV')
to line 72 fixes the problem (and the subsequent errors I got that you did not mention, which also seem to be related to using INV after it has a stale lastnum to create a new document).
Also, I'd be glad to get feedback on my way of solving this particular
problem, and I suggest to add this to the Django tests collection once I
got it working.
Well the problems the test reveal with the in-memory Journal instance having a stale lastnum after documents are deleted is a bit of a gotcha with they way you have set this up. Though it's easily fixed in the test, I fear actual code that uses these models would easily run afoul of the same problem.
And I don't see why you are focused on adding tests for these models to Django itself. Tests for your app's models belong with your app, not in the Django test suite.
Karen
Luc Saffre
> Well the problems the test reveal with the in-memory Journal instance
> having a stale lastnum after documents are deleted is a bit of a gotcha
> with they way you have set this up. Though it's easily fixed in the
> test, I fear actual code that uses these models would easily run afoul
> of the same problem.
Thanks, Karen, for your explanations. Now I understood the problem. Yes,
the other errors produced by this example were of course due to the same
mistake.
But what can I do to avoid this gotcha? Is there a better way to set
this up?
> And I don't see why you are focused on adding tests for these models to
> Django itself. Tests for your app's models belong with your app, not in
> the Django test suite.
I thought that this simplified case has some didactic value... but you
are right, I won't insist on having them added to Django.
Luc
Karen Tracey
Thanks, Karen, for your explanations. Now I understood the problem. Yes,
On 4.06.2009 19:46, Karen Tracey wrote:
> Well the problems the test reveal with the in-memory Journal instance
> having a stale lastnum after documents are deleted is a bit of a gotcha
> with they way you have set this up. Though it's easily fixed in the
> test, I fear actual code that uses these models would easily run afoul
> of the same problem.
the other errors produced by this example were of course due to the same
mistake.
But what can I do to avoid this gotcha? Is there a better way to set
this up?
My first thought would be to not store that value in a model at all, but rather pull it from the DB as max of the appropriate column when needed.
Karen
Luc Saffre
> My first thought would be to not store that value in a model at all, but
> rather pull it from the DB as max of the appropriate column when needed.
Yes, that would make things easier and more straightforward.
But some features that are easy with my setup will then become more
difficult:
- leave out a series of numbers and create them later
- start a journal with another number than 1
- create a document with a manually attributed number to fill a hole
But thinking now about it, I have the feeling that you are right: I'll
use the straightforward method ,and I will just have to use different
ways to solve the exceptional cases.
Thanks for your thoughts and greetings from Estonia!
Luc