On 19/07/2013 12:05pm, Victor Hooi wrote:
Hi,

Actually, while we're there - is this a suitable use of AutoField? Or is
there a better way to generate unique transactions IDs? python.uuid? Or
something better?

It depends on your use-case.

If your unique transaction number requirement is only short term, for example delivery tracking, you can almost guarantee it doesn't matter if you restart the numbering in future then you *could* use the id.

It only really matters if there is money and accounting involved. That is where most of my experience has been. Hence my own "rule" to never use a PK for transaction numbers. I have generally used a singleton method which saves its state on receiving a close signal.

Autofield is good if you are comfortable managing restoration from backup so your next transaction number satisfies your own business rules. Sometimes it matters whether such numbers are really sequential. If so and you can't tweak the next number you might have to perform dummy transactions until the numbers satisfy you.

If you build your own generator you need something which doesn't prove to be a bottleneck when your system scales up.

python.uuid solves such problems but may not suit your needs.

hth

Mike




Cheers,
Victor

On Friday, 19 July 2013 11:57:21 UTC+10, Victor Hooi wrote:

    Hi,

    Ok, thanks, I'll generate my own AutoField to track each transaction.

    Just to clarify - when you say they'll be issues with migration,
    what do you mean? Is it because that field is also as a FK to other
    models? Or something else?

    Cheers,
    Victor

    On Friday, 19 July 2013 11:50:25 UTC+10, Mike Dewhirst wrote:

        On 19/07/2013 11:31am, Victor Hooi wrote:
         > Hi,
         >
         > I'm just wondering - is it considered good or bad practice to
        use a
         > Django model's in-built ID field?
         >
         > Say for example you wanted a unique identifier for each
        transactio -
         > should you be generating your own, or can you use just
        self.id <http://self.id>?

        Don't go there. Generate your own. Consider what might happen if
        you
        needed to migrate to a different database or platform. The id
        integer
        will be a nightmare to manage so the unique transactions retain
        their
        original numbers.

        Mike


         >
         > Cheers,
         > Victor
         >
         > --
         > You received this message because you are subscribed to the
        Google
         > Groups "Django users" group.
         > To unsubscribe from this group and stop receiving emails from
        it, send
         > an email to django-users...@googlegroups.com.
         > To post to this group, send email to django...@googlegroups.com.
         > Visit this group at
        http://groups.google.com/group/django-users
        <http://groups.google.com/group/django-users>.
         > For more options, visit
        https://groups.google.com/groups/opt_out
        <https://groups.google.com/groups/opt_out>.
         >
         >

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to