Getting the project set up and running locally about pokeapi HOT 11 CLOSED

You still running into issues? "dev_data" isn't totally necessary. You could avoid this step by just running the first part of "make setup"

python manage.py migrate --settings=config.local

which will apply migrations to the sqlitedb
I actually keep forgetting about this and just end up working about the full postgres environment by running without explicit settings.

python manage.py migrate

Either should work fine because the v2 data build script should run against either database with no issue.

I've got to run for now but I'll try and help out more. Let me know if this has helped at all. I'll do my best to get you up and running

from pokeapi.

Is it necessary to run the migrations against the sqlite db? I should be able to run everything against postgres, no?

Here's exactly what I just did, step by step:

1. I erased my current postgres db and initialized another with initdb /usr/local/var/postgres
2. Then I followed the instructions laid out by Studnicky here, setting up the correct user and database.
3. Then I ran python manage.py migrate

It gets up until applying the 0001_squashed migration, then in the python console I get this error message:

~/Workspace/github/pokeapi (git: master) » python manage.py migrate
System check identified some issues:

WARNINGS:
?: (1_6.W001) Some project unittests may not execute as expected.
    HINT: Django 1.6 introduced a new default test runner. It looks like this project was generated using     Django 1.5 or earlier. You should ensure your tests are all running & behaving as expected. See https://docs.djangoproject.com/en/dev/releases/1.6/#new-test-runner for more information.
Operations to perform:
  Synchronize unmigrated apps: corsheaders
  Apply all migrations: hits, sessions, admin, pokemon_v2, sites, auth, tastypie, contenttypes
Synchronizing apps without migrations:
  Creating tables...
    Creating table corsheaders_corsmodel
  Installing custom SQL...
  Installing indexes...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying hits.0001_initial... OK
  Applying pokemon_v2.0001_squashed_0013_auto_20150420_0114...Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in     execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/base.py", line 288, in  run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/base.py", line 338, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 160, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "/usr/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 63, in migrate
    self.apply_migration(migration, fake=fake)
  File "/usr/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 97, in apply_migration
    migration.apply(project_state, schema_editor)
  File "/usr/local/lib/python2.7/site-packages/django/db/backends/schema.py", line 83, in __exit__
    self.execute(sql)
  File "/usr/local/lib/python2.7/site-packages/django/db/backends/schema.py", line 99, in execute
    cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/site-packages/django/db/utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: column "introduces_in_version_group_id" does not exist

and in my postgres console I see:

~/Workspace/github/pokeapi (git: master) » postgres -D /usr/local/var/postgres                                                                                                                                                                                                                        
LOG:  database system was shut down at 2015-09-12 18:17:09 EDT
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
ERROR:  column "introduces_in_version_group_id" does not exist
STATEMENT:  CREATE INDEX pokemon_v2_pokemonform_fc423f85 ON "pokemon_v2_pokemonform" ("introduces_in_version_group_id")

I'm not sure what I'm doing wrong. I have the database created with the proper name and owner, but I'm guessing the proper tables aren't being created/populated. Is the migration running out of order? I don't need to run the v1 migration (execfile('data/v1/build.py')) or anything first right?

from pokeapi.

I'm not sure how it happened but I would assume somehow the migrations are out of sync with with models. Maybe run makemigrations before running migrate? This should scan the models for changes and rebuild the migrations.

The field should be introduced_in_version_group_id
So if makemigrations doesn't work then maybe just going into the migration file and editing it manually might work. Probably not the best thing to do but I bet it'll fix the issue.

from pokeapi.

Ok, so in the migration file, there was a migration

migrations.CreateModel(
    name='PokemonForm',
    fields=[
        ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
        ('name', models.CharField(max_length=100)),
        ('order', models.IntegerField()),
        ('form_identifier', models.CharField(max_length=30)),
        ('is_default', models.BooleanField(default=False)),
        ('is_battle_only', models.BooleanField(default=False)),
        ('is_mega_form_order', models.BooleanField(default=False)),
        ('introduces_in_version_group', models.ForeignKey(blank=True, to='pokemon_v2.VersionGroup', null=True)),
        ('pokemon', models.ForeignKey(blank=True, to='pokemon_v2.Pokemon', null=True)),
    ],
    options={
        'abstract': False,
    },
    bases=(models.Model,),
),

and later on:

migrations.RenameField(
    model_name='pokemonform',
    old_name='introduces_in_version_group',
    new_name='introduced_in_version_group',
),

which I guess wasn't behaving as expected. I'm assuming this was meant to fix the typo, but I fixed the typo in the first migration object and commented out the renaming one, and the process succeeded.

Then I was able to run execfile('data/v2/build.py'), and it finally worked! All of the data was loaded into postgres. Thank you so much, I never would have thought to change the migration file itself, since I assumed django would know how to deal with it.

I do have another problem now though. When I start it up (using config.settings, not config.local since that configuration points to sqlite and I want postgres) and hit /api/v1/pokemon/1 for example, I get the error message that the pokemon_pokemon table doesn't exist. Sure enough, when I investigate in psql it doesn't, but pokemon_v2_pokemon does. I know django creates the table names based on the application name, but any idea why the Pokemon model wouldn't be looking at tables prefixed with pokemon_v2? I'm not sure where that configuration even leads.

from pokeapi.

/api/v1/pokemon would be meant only for serving v1 resources. When running that build script you're only building the v2 resources. Its odd that the pokemon_pokemon table doesnt exist though. Migrations should have created that. Maybe the pokemon app isnt included in the settings file. Make sure you've got
this in place. And then try to migrate again? 'pokemon' was commented out in mine at first.

CUSTOM_APPS = (
    'tastypie',
    'pokemon',
    'pokemon_v2',
    'hits',
)

Even then though, I've never built out the v1 resources. That might be more @phalt to chime in on cause I'm still pretty ignorant to python. Most of my involvement here has been pouring over the django docs.

/api/v2/pokemon is where pokemon v2 resources will be serving but currently none of the wiring is done to serve pokemon resources on v2. I've been workin on the v2 api for the last week or so.
https://github.com/zaneadix/pokeapi/tree/rest-framework
This has been my dev branch for the v2 api.

API urls are in config/urls.py for both v1 and v2.
V1 api resources under pokemon/api.py
V2 api resources under pokemon_v2/views.py

That should point you in the right direction

from pokeapi.

Ok, so adding 'pokemon' to CUSTOM_APPS in config/settings.py caused the pokemon_xxx tables (pokemon_pokemon, pokemon_move, etc) to be created, which is good, I guess. The problem is that there's no data in those tables. I suppose I could run execfile('data/v1/build.py'), but from my understanding that's not the direction this project is headed, if it's heading away from the v1 data.

So really the last problem is that for the v1 models, their db_table property still defaults to a pokemon_ prefix instead of the pokemon_v2_ prefix. I'll investigate the django docs, because I hope there's a way of changing that across all old models aside from manually adding the db_table property in every single one.

from pokeapi.

Hmmm. Im not sure what you're shooting for with the v1 models. Are you trying to have them fetchable through v2 as well? From what I would assume is they would stay in place just the way they've been and would be accessed just the same. Could you elaborate on exactly what task you're trying to take on?

Running execfile('data/v1/build.py') wouldn't do anything because its a set of methods that are written to be called individually i.e. build_pokes() to build out the pokemon. I opted to do the v2 build as a single executable script (though it probably should be enhanced to allow for building any of the models individually through some sort of dynamically executable method.

Once we have all of this worked we should definitely update the readme to make it a bit more explicit.

from pokeapi.

Well when we call /api/v1/pokemon/1, it calls into pokemon.api.PokemonResource whose queryset is Pokemon.objects.all() using the pokemon.models.Pokemon model. My knowledge of django isn't expert-level, so I could be wrong, but that model accesses the pokemon_pokemon table, since the app name under which the model was created was pokemon, so it creates the table with that prefix.

You're currently working on v2 routes which will use the models under the pokemon_v2 package - which will in turn access the pokemon_v2_ database tables. So is it correct that there currently no ways of accessing the v2 data from a route? If that's the case, then I can probably just run the functions in data/v1/build.py and build out the pokemon_ tables, until the v2 routes exist which use the pokemon_v2_ tables.

Please correct me if I'm wrong in anything I've said.

from pokeapi.

All of this is right. I was really just wondering if theres any part of the project you were looking to contribute to specifically just to make sure I was pushing you in the right direction. If you wanted to work against some of the v2 stuff you can definitely pull down my branch and go from there. There are a handful of resources being served, just not fully fleshed out. Abilities and Types are pretty full featured. It would actually be a great help to me if you did do that so you can take a look at the data being served and help identify any weak points or just start a general discussion of what the datasets should even look like.

from pokeapi.

I could definitely do that.

The first thing I wanted to do was add a property like display_name to Pokedex, since consuming the endpoint and getting back values like mime-jr isn't really that useful since I'd either have to call ~700 endpoints to get the full name, or have my own mapping from mime-jr to Mime Jr., for example.

The other thing I wanted to add was either pre-evolutions or evolutions as their own resource such that if you called the endpoint for any id in an evolution set, you get that evolution set. Looking at the evolutions property of Venusaur doesn't tell you anything about Bulbasaur, but calling api/evolutions/3 would effectively be the same as api/evolutions/1 or api/evolutions/2.

Those are just some ideas I've had so far. I'd also like to set up the environment with Vagrant, as that will take out the inconsistencies when getting everything up and running.

from pokeapi.

Display_Name
This is something I've been thinking about as well. I currently have lists of resources returning something like this

pokemon_entries: [
{
   entry_number: 1,
   pokemon: {
      name: "bulbasaur",
      url: "http://localhost:8000/api/v2/pokemon/1/"
   }
},
{
   entry_number: 2,
   pokemon: {
      name: "ivysaur",
      url: "http://localhost:8000/api/v2/pokemon/2/"
   }
}
]

The problem with this is that pokemon resources (as well as pretty much all others) dont just have a single name anymore. Heres an example of Normal types "names" attribute.

names: [
{
    name: "Normale",
    language: {
        name: "it",
        url: "http://localhost:8000/api/v2/language/8/"
    }
},
{
    name: "Normal",
    language: {
        name: "en",
        url: "http://localhost:8000/api/v2/language/9/"
    }
}
],

So to be able to set the "Display_Name" attribute on a resource we would need a default language and would need to allow a user to provide a query value to choose their default language. At least thats the best way I could think to handle it.

Evolutions
This is an interesting idea. It would definitely be more of a secondary feature in my opinion. Considering the nature of the data and the limit of 30 calls per resource per day (that I would imagine should carry over from v1) this would most likely be something a consumer would produce on their end after making calls and caching data.

Maybe we should push this sort of discussion to a different issue.
Especially the Vagrant set-up. That would be a great task to tackle

from pokeapi.