Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why focusing on one DB? #23

Open
sternenseemann opened this issue Oct 29, 2013 · 5 comments
Open

Why focusing on one DB? #23

sternenseemann opened this issue Oct 29, 2013 · 5 comments

Comments

@sternenseemann
Copy link
Contributor

In the last Discussions there often was metioned CouchDB (or MongoDB). I don't think that GDS should have a main Database because Developers shouldn't be forced to use a specific DB.
Of course you can install another DB but if there's a standard or deafault database software that's not a good sign especially under the aspect of openness.

@janl
Copy link

janl commented Oct 29, 2013

For the level of discussion that is relevant at this point, “DB” should be considered an abstract concept that enables user-driven features. Eventually, “DB” can have multiple different backing stores that translate directly to a specific database.

FWIW, CouchDB is probably brought up because it was designed for such an endeavour, but I’d say that it is too early to commit to any particular technology.

@augustl
Copy link
Contributor

augustl commented Oct 29, 2013

I think this is a very interesting topic.

Perhaps GDS should just provide raw file system access, so that one
would have to implement databases specifically for GDS. This isn't as
crazy as it might sound, you probably just need a single threaded global
write lock database since it doesn't have to scale to gazillions of
users. So you won't have to re-implement postgresql or couchdb in full.

There's also discussions around sandboxing and dependencies, and some
sort of package system, so that an app could say that it needs postgres
9.1 and another says it needs postgres
8.0, and GDS manages these so that multiple instances of whatever
dependencies the apps requires to be present.

In any case, I think it makes sense that databases, regardless of
methodology, are completely app private, so that data is shared over
HTTP (?) APIs. That way, an app can be rewritten to use a completely
different database, and nobody will have to know.

On 10/29/2013 05:45 PM, Lukas Epple wrote:

In the last Discussions there often was metioned CouchDB (or MongoDB).
I don't think that GDS should have a main Database because Developers
shouldn't be forced to use a specific DB.
Of course you can install another DB but if there's a standard or
deafault database software that's not a good sign especially under the
aspect of openness.


Reply to this email directly or view it on GitHub
#23.

@sternenseemann
Copy link
Contributor Author

Of course I have to say the GDS core apps must use one Database System (for example CouchDB) to work that must be preinstalled.

@augustl
Copy link
Contributor

augustl commented Oct 29, 2013

@lukasepple not necessarily, if they communicate using defined APIs, they too can keep the DBs private. Also, I think it's important that the core apps are replaceable through intents, as described in apps.md, so a shared hardcoded database sounds a bit dangerous to me.

@sternenseemann
Copy link
Contributor Author

@augustl i meant that the private DB of the core apps must be preinstalled if that wasn't clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants