1. Discarding EDS

Forked from Re: Euphoria MVC updates

euphoric said...
Bhupen1277 said...

It is about time Euphoria EDS was discarded in favour of something very close to SQL

This might be a good idea, to have a more serious database system immediately available after install.

Heck, it would be a good idea to have a MySQL/PostgreSQL/Maria DB/Mongo DB interface immediately available after install.

Maybe there already is one. I don't know. grin

I think EDS has its merits and I have no intention to discard it. If I anyone can dig out Derek's improvements I'd like to see them implemented in the main source.

That being said, I do plan to ship my SQLite wrapper from Euphoria MVC with Euphoria 4.2 and include SQLite in the build process so it ships the latest version each time.

In fact several things I've written for Euphoria MVC will actually be moved to Euphoria at some point: JSON/template parsers, SQLite/CURL wrappers, etc.

-Greg

new topic     » topic index » view message » categorize

2. Re: Discarding EDS

ghaberek said...

In fact several things I've written for Euphoria MVC will actually be moved to Euphoria at some point: JSON/template parsers, SQLite/CURL wrappers, etc.

😍

new topic     » goto parent     » topic index » view message » categorize

3. Re: Discarding EDS

euphoric said...
ghaberek said...

In fact several things I've written for Euphoria MVC will actually be moved to Euphoria at some point: JSON/template parsers, SQLite/CURL wrappers, etc.

😍

The only reason I wrote most of those libraries was because I needed them to bootstrap Euphoria MVC, but they have broader use and belong in the standard library.

I think Euphoria MVC will eventually be just a command line tool that reuses those things from the standard library and facilitates managing a web application project itself.

-Greg

new topic     » goto parent     » topic index » view message » categorize

4. Re: Discarding EDS

The main and only reason I suggested discarding EDS is the fact that DBF, although older and much more supported is not generally accepted by the large programming community. Hadoop has connection to DBF but not to EDS. As it is, Euphoria has very little acceptance within the programming world and to impose a different database system (however good it might be) would be unacceptable. I think in Euphoria, I have seen many efforts at connection to SQL type of databases and it would be best to direct your efforts towards that.
No offense meant to anybody. I am myself a DBF fan and expert, but have accepted its demise.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Discarding EDS

Bhupen1277 said...

The main and only reason I suggested discarding EDS is the fact that DBF, although older and much more supported is not generally accepted by the large programming community. Hadoop has connection to DBF but not to EDS.

DBF as in dBASE format? That takes me back. I used to work with a bunch of folks who came from Fox Software after they got bought out. It was always fun hearing about IT and programming stuff from that era.

Although I fail to see how the existence of DBF and Hadoop's support for any format has any bearing on Euphoria's own database format?

Bhupen1277 said...

As it is, Euphoria has very little acceptance within the programming world and to impose a different database system (however good it might be) would be unacceptable.

I think it's a bit unfortunate that Rob Craig called EDS a "database" because it's really just key-value format. It's been very good to have as a general-purpose lightweight data storage system. But I wouldn't really call it a database nowadays.

No one here is trying to push EDS as a solution to the greater world. But EDS works because it was written from scratch to support Euphoria objects. Nothing else in the world "speaks" Euphoria at that level.

In that way EDS is a lot more like Python's shelve library than anything else, which uses the pickle library to store objects in a file.

Bhupen1277 said...

I think in Euphoria, I have seen many efforts at connection to SQL type of databases and it would be best to direct your efforts towards that.

This is certainly the path forward yes. We do need more inclusive and welcoming options for newcomers, and we can offer that by providing access to systems they already use. But that doesn't mean we have to completely abandon anything either.

-Greg

new topic     » goto parent     » topic index » view message » categorize

6. Re: Discarding EDS

I think EDS is fine for personal databases/projects. Its probably best not to use if you plan on having a big database. Having MySQL/SQLLite bundled together with Euphoria will be great. As will the memstruct feature. I don't see a reason to discard EDS.

new topic     » goto parent     » topic index » view message » categorize

7. Re: Discarding EDS

ghaberek said...

No one here is trying to push EDS as a solution to the greater world.

That gave me an idea. Not that I'm planning on deliberately damaging any of them, but shifting database, console graphics, and message_box down to the deprecated section of the Phix docs is clearly an improvement.

new topic     » goto parent     » topic index » view message » categorize

8. Re: Discarding EDS

ghaberek said...

I think it's a bit unfortunate that Rob Craig called EDS a "database" because it's really just key-value format.

If maps are writable to disk, then what's the need of EDS? (Just curious.)

Or, what's the different use-case for maps and EDS?

new topic     » goto parent     » topic index » view message » categorize

9. Re: Discarding EDS

euphoric said...
ghaberek said...

I think it's a bit unfortunate that Rob Craig called EDS a "database" because it's really just key-value format.

If maps are writable to disk, then what's the need of EDS? (Just curious.)

Or, what's the different use-case for maps and EDS?

Mostly it comes down to memory usage. Maps are an "all or nothing" approach with all keys and values stored in memory at once, which makes it very fast. EDS only loads the keys of the selected table into memory and then only retrieves the values from disk when you ask for them, which makes it quite a bit slower. But these differences aren't strictly about memory consumption: you could probably fit most EDS databases entirely in memory without issue, but when keeping everything in memory, if your app crashes all of our maps go with it. EDS at least keeps most things on disk most of the time, so you're never really in an unsafe state unless you crash during a write, which is what Derek's improvements had tried to correct. And behind the scenes they're quite different as well. They may be the same "here is a key please give me the value" kinds of systems, but EDS ensures table keys are always sorted and uses binary search to locate its records, while maps don't care what order things are in and relies on hashing and buckets to its locate records. The differences in performance might start showing at massive scales, but I'm not sure anyone is pushing either system that hard. As far as use case, that's mostly down to occasional access and long-term storage (EDS) versus frequent access and short-to-zero-term storage (maps). Think of EDS like a library and maps like a phone book.

-Greg

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu