Data Dumps

[Daniel]

Is our data dump a straight data dump or is their some processing done? I am specifically after two things: is the data structure for the data dump identical to the database schema? and are all the tables and every row included in the dump?

Daniel

[Lionel English]

None of the admin tables are included--the ones with user info.  Nor are the tables related to the pending changes or change-histories included--just the current data.  I'll defer to the other tech guys for a more detailed answer.

On Wed, Aug 29, 2012 at 4:19 PM, Daniel <nausc...@yahoo.com> wrote:

Is our data dump a straight data dump or is their some processing done?  I am specifically after two things: is the data structure for the data dump identical to the database schema?  and are all the tables and every row included in the dump?

Daniel

--
GCD-Tech mailing list - gcd-...@googlegroups.com
To unsubscribe send email to gcd-tech+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/gcd-tech

--
Lionel English

San Diego, CA
lio...@beanmar.net

[Daniel]

Darn! You just threw a spanner into the works. Your answer actually implies that my database design is incomplete. I suspect you know i will ask and pester for details. :)

Daniel

[Alexandros Diamantidis]

To add to Lionel's answer, not all rows of the data tables are in the
dumps - the dump script filters out the rows corresponding to deleted
objects by adding a "WHERE deleted=0" to the mysqldump command.

I don't think it's worth it to spend any time documenting the non-public
tables. These only concern our web app and anyone doing any development
on our code won't be accessing the database directly, they'll be using
the Django ORM. This is the recommended and sensible way to work with
the data, as Python objects - any information on the tables themselves
would be a distraction to new developers trying to find their way around
our code. They would be much better served by reading the model source
code which is quite readable if you are familiar with Django.

Alexandros

* Lionel English [2012-08-29 16:23]:

[Daniel]

I understand, but i am not documenting this for other developers or external users. This is for us, and if I learn that there is no desire for this document with GCD, then I am doing this for me. :)

Daniel

Alexandros Diamantidis <ad...@hellug.gr> wrote:

[Alexandros Diamantidis]

* Daniel [2012-08-30 06:53]:

> I understand, but i am not documenting this for other developers or external users. This is for us, and if I learn that there is no desire for this document with GCD, then I am doing this for me. :)

Ok... It's just that I don't see this as very useful, even for us, and
it's a huge amount of work, so I though I'd warn you! The nice thing
about Django's ORM is that it frees us from having to deal with SQL
directly and instead manages everything (or as close as possible)
automatically.

So... I'm attaching the results of "show create table' for all the
tables (67 in total). Note that they were created automatically by
Django based on our models and that's why the indexes and foreign keys
have non-descriptive names like "gcd_issue_ibfk_2".

The django_* and auth_* are created by Django itself and its
authentication framework, and the two taggit_* tables by the keywords
library we're using.

The oi_*_revision correspond to the gcd_* tables and hold the changed
records in each changeset to the corresponding object (for example,
oi_series_revision contains the changes to a gcd_series record, with a
foreign key to oi_changeset).

voting_* is of course the voting app.

Alexandros