Out of date Oracle text

[Jonathan Bettger]

So I just realized we have a ton of out of date Oracle text. We don't really update older card's oracle text. The quickest example currently is something like Boros Charm. "are indestructible" is now "gain indestructible". Just in the 2014 Core set update, between that and unblockable being changed to "Cannot be blocked" over 200 cards are out of date. So who wants to help get the ball rolling to fix this?

My brainstorm currently requires programming something up that can compare 2 databases. One database being the current database in app, the other being a full regrab of the database from Gatherer.

Or do we already have something in place, and I just totally missed it?

[Jesse Kinkead]

I don't fully understand the dataflow yet - new card sets are uploaded as separate files, fetched by the phone app, right? And from what I can tell, these get inserted into the sqlite database only - no deletes or updates?

--
You received this message because you are subscribed to the Google Groups "MTG Familiar Devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtg-familiar-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[April King]

Just do an md5sum of our database and compare it to one regularly compiled against Gatherer?

--

[Adam Feinstein]

There are two ways of updating the database. The more frequent one uses the individual set files, downloads them on the fly, and inserts them into the database. This is nice because it doesn't require rereleasing to Google Play. The other way is repackaging a new database in an update through Google Play which overwrites the older database.

When Wizards makes sweeping oracle changes, I redownload the whole thing, build the sqlite from scratch, and repackage that. I'll get the ball rolling this weekend and have it in 2.1.1, which suddenly becomes a more pressing release. I'll also go through the to-do list and changelogs this weekend. If we're lucky, the only other thing to do will be some translation strings.

[Jonathan Bettger]

Oh so Adam already does it. Never mind.
Pay no attention to me.

Distrction: How's goes it everyone?

[April King]

It's great!  I have a new super duper secret plan for the rules bits, but I need Alex to message me... that slacker.

[Adam Feinstein]

Well, he took my copy of Game of Thrones on vacation, so you won't hear from him for a bit.

[Jesse Kinkead]

Thanks, that matches my vague impressions . . .

So, that was secretly a leading question, because I'd been looking into the database as a place to store card lists, and was trying to figure out the feasibility of foreign keys into the cards table. If the rows on that table aren't deleted, or are restored from a file with the PK in it, it should work OK.

Any opinions on FKs in general? I notice the current db isn't normalized, and perhaps there's a reason behind that?

On Jul 12, 2013 12:13 PM, "Adam Feinstein" <gelak...@gmail.com> wrote:

[Adam Feinstein]

You've lost me a little there. What is a foreign key, FK, PK, and normalized database? (I'm not much of a databases person, or even a CS major!)

In general it isn't wise to use the database to store things, since it is prone to getting overwritten on app updates. Wishlists, tradelists, and cached price info are all stored in files, you'll notice.

[Jonathan Bettger]

FTFY

"In general it isn't wise to use the database to store things, since over 90% of our crashes come from messing with it."

I can answer a little foreign key = FK and PK is primary key.

[April King]

Well then.  How about this bad boy:

www.twoevils.org/files/tmp/rules.db.gz

As being used instead of our current setup?  It has all three rules documents (and more!) in one nice tidy file.

[Adam Feinstein]

I don't know how well that will jive with Alex's current setup for working with rules. We'll see when he gets back.

[Jesse Kinkead]

Hah!

It's my understanding that the SQLite database in an android app is *theoretically* a long-term storage for data. From reading the documentation (admittedly, ages ago) I got the impression that it meant a lot of bookkeeping in your app, and lots of legacy upgrade SQL lying around for a long time, or dropping and re-creating your tables on update. I definitely won't use the DB unless it looks to be preservable reliably on app updates (and probably backing up to a file, which looks like the rest of the app does?)

30-second FK / normalization: A normalized database doesn't repeat information, basically. So, if you had a 'wishlist' table, you might have a 'card_id' column instead of a 'card_name' / 'set' / 'mana_cost' / etc. columns, where the card_id matched the _id of the cards table. This would be a normalized relationship, and the card_id is a foreign key into the cards table.

[Adam Feinstein]

Yeah, the SQLite database is persistent in theory, but not in this practice. As with most projects, I made some questionable design decisions based on my limited knowledge of SQLite at the outset which have been easier to live with than fix.

On that subject, I checked in the rebuilt database with updated oracle text.

Not on that subject, we broke the 100k active user mark two days ago. Go team!

[Jesse Kinkead]

Nice on the 100k users!

That change also answered one question I had on the database - the sharing of DATABASE_VERSION between the card data version (incremented when card data is updated) and the schema version (as sent to the SQLiteOpenHelper: https://code.google.com/p/mtg-familiar/source/browse/trunk/MTGFamiliar/src/com/gelakinetic/mtgfam/helpers/CardDbAdapter.java?spec=svn830&r=830#187).

Going forward, if schema changes are made, these numbers should be separated - else, you run the risk of updated card data causing a user to skip a DB schema update. Well, assuming you implement a version-checked onUpgrade method in the DatabaseHelper. ;)

- jesse