Ack - backward compatibility issue with Blueprints

9 views
Skip to first unread message

David Winslow

unread,
Aug 20, 2013, 12:53:06 PM8/20/13
to GeoGit
It seems that Blueprints reserves a few property names for its own usage, one of those being "id".  Since we currently use a property named "id" for storing object checksums I guess we cannot write a Blueprints backed store that is compatible with repos created before the Blueprints port.

Is it a showstopper?  Probably not, since any of the non-neo4j databases that we might use with Blueprints would also be incompatible.  But I'd be interested to hear if this is a concern.

--
David Winslow

Gabriel Roldan

unread,
Aug 21, 2013, 8:35:05 AM8/21/13
to David Winslow, GeoGit
I would like us to keep being free of changing _anything_ until we reach 1.0.0, then start to be more conservative and think of backwards compatibility. But for the time being just lets make a note on the docs/release note whenever some change makes repos created with a previous minor version unusable.

I'm not sure if LMN will be as open as I am on this regard, lets hear from them.

Cheers,
Gabriel.
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Scott Clark

unread,
Aug 21, 2013, 4:38:57 PM8/21/13
to Gabriel Roldan, David Winslow, GeoGit
Our main concern is that no breaking changes are made before middle of September.

Scott

August 21, 2013 6:35 AM
I would like us to keep being free of changing _anything_ until we reach 1.0.0, then start to be more conservative and think of backwards compatibility. But for the time being just lets make a note on the docs/release note whenever some change makes repos created with a previous minor version unusable.

I'm not sure if LMN will be as open as I am on this regard, lets hear from them.

Cheers,
Gabriel.
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
To unsubscribe from this group and stop receiving emails from it, send an email to geogit+un...@opengeo.org.
August 20, 2013 10:53 AM
It seems that Blueprints reserves a few property names for its own usage, one of those being "id".  Since we currently use a property named "id" for storing object checksums I guess we cannot write a Blueprints backed store that is compatible with repos created before the Blueprints port.

Is it a showstopper?  Probably not, since any of the non-neo4j databases that we might use with Blueprints would also be incompatible.  But I'd be interested to hear if this is a concern.

--
David Winslow
To unsubscribe from this group and stop receiving emails from it, send an email to geogit+un...@opengeo.org.

Jeffrey Johnson

unread,
Aug 22, 2013, 5:15:43 PM8/22/13
to Scott Clark, Gabriel Roldan, David Winslow, GeoGit
Might just make sense to wait to pull this one until after the OD, just before the 0.5 release at the end of that week and make sure we note it in the release notes.

Dwins did think it was straightforward to make a conversion tool that would convert an existing repo to this format, but other than ROGUE, Im not sure if that will matter to anyone other than perhaps Nick Dorian?
postbox-contact.jpg
postbox-contact.jpg
Reply all
Reply to author
Forward
0 new messages