Progress on the backend part
27 views
Skip to first unread message
Morten Olsen Lysgaard
Nov 11, 2013, 7:52:40 PM11/11/13
to openaviationmap
Hi, I have put down some more hours on the backend and it really
helps. Now I am able to import all navaids and aerodromes from a
OSM-XML dump of our database. It is easily extendable to more
features.
Right now I am looking at database versioning systems. There exist
some plug in systems that gives us versioning and undo/redo features
on database edits. This way we can more safely let people edit the
database without fearing for the data.
One such project is this one: https://github.com/etianen/django-reversion
If i get that working we have a programmable database with a web
interface for single edits and an API for batch edits. That's not to
bad.
helps. Now I am able to import all navaids and aerodromes from a
OSM-XML dump of our database. It is easily extendable to more
features.
Right now I am looking at database versioning systems. There exist
some plug in systems that gives us versioning and undo/redo features
on database edits. This way we can more safely let people edit the
database without fearing for the data.
One such project is this one: https://github.com/etianen/django-reversion
If i get that working we have a programmable database with a web
interface for single edits and an API for batch edits. That's not to
bad.
Akos Maroy
Nov 13, 2013, 7:14:40 AM11/13/13
to openavi...@googlegroups.com
Morten,
as you see, now we have Slovenia, Slovakia, and Switzerland will be the best
Akos
> Hi, I have put down some more hours on the backend and it really
> helps. Now I am able to import all navaids and aerodromes from a
> OSM-XML dump of our database. It is easily extendable to more
> features.
great!
> helps. Now I am able to import all navaids and aerodromes from a
> OSM-XML dump of our database. It is easily extendable to more
> features.
as you see, now we have Slovenia, Slovakia, and Switzerland will be the best
> Right now I am looking at database versioning systems. There exist
> some plug in systems that gives us versioning and undo/redo features
> on database edits. This way we can more safely let people edit the
> database without fearing for the data.
cool
> some plug in systems that gives us versioning and undo/redo features
> on database edits. This way we can more safely let people edit the
> database without fearing for the data.
> One such project is this one: https://github.com/etianen/django-reversion
> If i get that working we have a programmable database with a web
> interface for single edits and an API for batch edits. That's not to
> bad.
>
sounds excellent!
> If i get that working we have a programmable database with a web
> interface for single edits and an API for batch edits. That's not to
> bad.
>
Akos
Morten Olsen Lysgaard
Nov 27, 2013, 7:25:04 PM11/27/13
to openaviationmap
I have been thinking a bit and gotten a nice idea. PostgreSQL supports
key value columns named hstore and json objects. Maybe we should allow
all objects to have additional extra attributes that are a JSON field.
Then, when we see a specific pattern in the JSON I can write
migrations to explicityl state them in the schema instead of the JSON
column. That way we can start with a small set of attributes to each
object, and evolve our schema based on what fields we use in our NoSQL
column.
Should be quite straight forward and I believe it would give people
adding data an "escape hatch" when the current schema doesn't fit.
What do you think?
> --
> You received this message because you are subscribed to the Google Groups
> "openaviationmap" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openaviationm...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
key value columns named hstore and json objects. Maybe we should allow
all objects to have additional extra attributes that are a JSON field.
Then, when we see a specific pattern in the JSON I can write
migrations to explicityl state them in the schema instead of the JSON
column. That way we can start with a small set of attributes to each
object, and evolve our schema based on what fields we use in our NoSQL
column.
Should be quite straight forward and I believe it would give people
adding data an "escape hatch" when the current schema doesn't fit.
What do you think?
> You received this message because you are subscribed to the Google Groups
> "openaviationmap" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openaviationm...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages