Hi Mark, I don't really know what to make of that thread and I wouldn't pretend to understand everything thats being talked about here or there....so i'm jst thinking out loud.
I believe I might have mis-spoken by calling it a driver..... its really a LC external that acts as a driver. If you go to this page ..... the specs say that it all happens through an tcp/ip connection where you make a connection, serialize the query and send it .... the db driver port receives queries, and streams data from the db via the TCP/IP back to "subscribed" client. So it doesn't really need to have anything to do with the current revdatabase functions....which the posts seem to be talking about. I'm not asking for a rewrite of db layer. It would be more perform ant to build this as an external and closer to the engine...as far as I know anyways..... unless thats completely wrong. Here is the link again....... https://www.rethinkdb.com/docs/writing-drivers/ Thanks for making me aware of the past efforts with RethinkDB. On Sat, Aug 5, 2017 at 4:36 PM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > Err - given that revDB is an *SQL* database wrapper and MongoDB is not an > SQL database you can imagine that creating an abstraction layer to deal > with both might be 'quite' hard - if not impossible. > > So, given that we've now been open source for over four years and as such > that code has been open for others to contribute to for four years please > feel free to try and propose an API which works relatively seemlessly for > all types of databases that exist today - I'll happily review it and help > ensure it is worthwhile. > > Less 'rants' and more actual intellectual effort please. This isn't down > to static and dynamic libraries, that is just the colour of the bikeshed at > this level - and trying to claim that anything related to that is the issue > here is just misleading people. > > Warmest Regards, > > Mark. > > P.S. My point here is simply that whilst their may be an abstraction which > unifies all databases it sits so far up in the abstraction hierarchy that > trying to make revDB do it would be entirely pointless. The 'revDB' rewrite > you speak of has been subsumed by a number of db libraries which solve the > issue of low-level access that revDB provides. Whether that be dblib, > sqlyoga, or the way to abstract in a domain specific case as typified in > many apps (e.g. The photo app in the createit course) have provided. > Indeed, let's not pretend that the issue with supporting all kinds of > 'database' here is at the C / API level because it really isn't. > > P.P.S. Abstractions are what makes things easy - abstracting too far and > all you end up doing is proving that 1 = 1 in numerous not particularly > interesting ways. What you might call "category theory 101". > > Sent from my iPhone > > > On 5 Aug 2017, at 19:39, Mark Wieder via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > >> On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote: > >> I have to admit that rethinkdb sounds really interesting - I hadn't > heard of it until your posting. > >> Might be worth a crowdfunding / donation request to spread the cost; > while I don't have a *need* for it, it might be a worthy target for (a > small amount) of my optional spending of my 'pocket money' ;-) > > > > <rant> > > http://quality.livecode.com/show_bug.cgi?id=3662 > > </rant> > > > > <rant continued> > > In 2006 all existing database bugs in bugzilla were rolled into one > omnibus 'revDB review' bug report, and the individual report statuses were > all changed as 'resolved'. This in favor of 'We will shortly be reviewing > revDB' for a major rewrite of the database layer. > > > > Had this actually been done anytime in the intervening eleven years, > adding new database types would be much easier. At some point I tried to > add mongodb to the engine and eventually hit a brick wall because of an > incompatibility with the existing library structure (a clash of static and > dynamic libraries, IIRC) > > > > I realize revamping the database layer is a bigger task than trying to > shoehorn more database types into the existing bucket, but I think it's > high time to revisit (crowdfund) this. Otherwise we're just digging > ourselves deeper into the existing muck. > > </whatever> > > > > -- > > Mark Wieder > > ahsoftw...@gmail.com > > > > _______________________________________________ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
