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.......
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 <
> 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,
> 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 <
> email@example.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
> > firstname.lastname@example.org
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription