quasi-distributed system sharing data in django

[Ricardo Pascal]

Hello folks,

I have two django projects, (let call them A and B) they are independent applications (with different django versions), I'm in need to sync some data/models from A to B. 

My plan is to use the post_save signal to start a celery task that will post a subset of data from A to B using the B API.

This new data will be stored in models at B and be used in relationships with data in B. (To make things easier, those data will never(probably) be created or updated from B application)

I'm seeing the necessity to keep the primary key on both applications synchronized too. 

My questions is: should I keep using the auto-increment id from django, or instead use some uuid as pk?

Also, any better idea on how to implement this? Tips, unforeseen problems or any rant about that matter will be appreciated.

Thanks in advance,

--
Att.
Ricardo Pascal

[Mike Dewhirst]

On 6/10/2016 7:40 AM, Ricardo Pascal wrote:
> Hello folks,
>
> I have two django projects, (let call them A and B) they are
> independent applications (with different django versions), I'm in need

> to sync some data/models from A to B.Â

>
> My plan is to use the post_save signal to start a celery task that
> will post a subset of data from A to B using the B API.
>
> This new data will be stored in models at B and be used in
> relationships with data in B. (To make things easier, those data will
> never(probably) be created or updated from B application)
>
> I'm seeing the necessity to keep the primary key on both

> applications synchronized too.Â
>
> My questions is: should I keep using the auto-increment id from

> django, or instead use some uuid as pk?

Ricardo

You say "never(probably)" and that sounds like a decision needs to be
made. I would always decide in favour of the easiest answer and the
least work right now.

Therefore I'd suggest using the Django auto-incrementing key in the B
project.

Synchronising keys across two projects feels ugly. If you can't decide
between "never" and "never(probably)" you could always add an
IntegerField to the applicable model class in project A to store a copy
of the primary key. Maybe use the migration and then the model save()
method to populate it.

At least then you would have a simple independent mechanism to find the
corresponding record in B should you ever need to update the data.

Mike

>
> Also, any better idea on how to implement this? Tips, unforeseen
> problems or any rant about that matter will be appreciated.
>
> Thanks in advance,
>
> --
> Att.
> Ricardo Pascal

> --
> 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
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAJ5FqeoypDP0520sNcpxC82NHAy-wbWbWs8RWXktPzyhDOXUFg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CAJ5FqeoypDP0520sNcpxC82NHAy-wbWbWs8RWXktPzyhDOXUFg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.