RE: SQLite déjà vu again
Greg, there is an article on the Red Gate / Simple-Talk website that you may be interested to read – Does NoSQL = NoDBA? https://www.simple-talk.com/opinion/opinion-pieces/does-nosql--nodba In passing, the author mentions a number of other NoSQL database systems - MongoDB, CouchDB, Cassandra, Riak, Voldemort. What interested me was the discussion of the CAP Theorem (in the context of distributed systems, Big Data) and “eventual consistency” of NoSQL queries, versus the enforced consistency of relational databases. From my reading, the absence of (a wider range of) typed data fields for NoSQL databases is probably because of their irrelevance - and the absence of GUID fields is of no concern in the context of their principal use cases. _ Ian Thomas Albert Park, Victoria From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Saturday, November 01, 2014 7:35 AM To: ozDotNet Subject: Re: SQLite déjà vu again Well, it's not all hugs and puppies, as BrightstarDB failed my very first test to use it in a real application. Its Entity Framework like layer does not support Guid properties. This is utterly inconceivable and unexpected, and it renders the library completely useless to me. I have posted into their forum suggesting that adding unconditional support for Guids must be of the highest priority -- Greg K On 31 October 2014 18:36, Greg Keogh g...@mira.net wrote: On 30 October 2014 19:19, osjasonrobe...@gmail.com wrote: BrightstarDB - http://brightstardb.com/ may be of interest… After fiddling with this for half an hour I'm starting to think this product is a work of art! It's pleasing to discover a managed product that is well thought-out, elegantly layered, (quite) well documented, well tooled, uncluttered, and free. I had the samples working in minutes without a glitch, and most importantly they worked in a really familiar style. You can work with two lower levels of API or at the higher entity level. They have VS templates to add interfaces from which a T4 template will generate EF-like entities. In fact they've mimicked EF with amazing fidelity, even relationship collections. It's weird to find a NoSql database that supports joins. I don't know yet how much of EF's IQueryable behaviour they've reproduced. They foolishly seem to have created their own query language called SPARQL. I'm going to investigate BrightstarDB in much more detail and I'll report any startling news. Anyone else here using it? Greg K
Re: SQLite déjà vu again
Does NoSQL = NoDBA? https://www.simple-talk.com/opinion/opinion-pieces/does-nosql--nodba Ah yes, a different type of DBA will evolve. From my reading, the absence of (a wider range of) typed data fields for NoSQL databases is probably because of their irrelevance - and the absence of GUID fields is of no concern in the context of their principal use cases. When I'm round-tripping stuff from managed code and any database I expect natural feeling CLR type support, I don't want to have to transform data as it goes in and out. I received a rapid reply from a BrightstarDB developer who had added Guid property support into their developer branch. I don't know if that includes support for Guids as primary keys, as I couldn't coax their latest source download into compiling. Cheers, Greg P.S. Have you moved to Vic from WA?
Re: SQLite déjà vu again
On 30 October 2014 19:19, osjasonrobe...@gmail.com wrote: BrightstarDB - http://brightstardb.com/ may be of interest… After fiddling with this for half an hour I'm starting to think this product is a work of art! It's pleasing to discover a managed product that is well thought-out, elegantly layered, (quite) well documented, well tooled, uncluttered, and free. I had the samples working in minutes without a glitch, and most importantly they worked in a really familiar style. You can work with two lower levels of API or at the higher entity level. They have VS templates to add interfaces from which a T4 template will generate EF-like entities. In fact they've mimicked EF with amazing fidelity, even relationship collections. It's weird to find a NoSql database that supports joins. I don't know yet how much of EF's IQueryable behaviour they've reproduced. They foolishly seem to have created their own query language called SPARQL. I'm going to investigate BrightstarDB in much more detail and I'll report any startling news. Anyone else here using it? *Greg K*
Re: SQLite déjà vu again
Well, it's not all hugs and puppies, as BrightstarDB failed my very first test to use it in a real application. Its Entity Framework like layer does not support Guid properties. This is utterly inconceivable and unexpected, and it renders the library completely useless to me. I have posted into their forum suggesting that adding unconditional support for Guids must be of the highest priority -- *Greg K* On 31 October 2014 18:36, Greg Keogh g...@mira.net wrote: On 30 October 2014 19:19, osjasonrobe...@gmail.com wrote: BrightstarDB - http://brightstardb.com/ may be of interest… After fiddling with this for half an hour I'm starting to think this product is a work of art! It's pleasing to discover a managed product that is well thought-out, elegantly layered, (quite) well documented, well tooled, uncluttered, and free. I had the samples working in minutes without a glitch, and most importantly they worked in a really familiar style. You can work with two lower levels of API or at the higher entity level. They have VS templates to add interfaces from which a T4 template will generate EF-like entities. In fact they've mimicked EF with amazing fidelity, even relationship collections. It's weird to find a NoSql database that supports joins. I don't know yet how much of EF's IQueryable behaviour they've reproduced. They foolishly seem to have created their own query language called SPARQL. I'm going to investigate BrightstarDB in much more detail and I'll report any startling news. Anyone else here using it? *Greg K*
Re: SQLite déjà vu again
Is it SQLite that is the nightmare, or ADO? It's a combination, but I perhaps blame SQLite a bit more because they lag behind but eventually catch-up with dependent tools and frameworks. You might do better running ODBC. Less layers, more independence.. Hmm, I'm not sure of the implications of that. Being a really strongly-typed kind of guy, I'm also irritated and puzzled by the original design decision to internally store SQLite data as strings and byte[] only. I would also like referential integrity, but you have to compile it yourself with a pragma on, and I'm not gong down that road of woe. GK
Re: SQLite déjà vu again
BrightstarDB - http://brightstardb.com/ may be of interest… Jason Roberts Journeyman Software Developer Twitter: @robertsjason Blog: http://DontCodeTired.com Pluralsight Courses: http://bit.ly/psjasonroberts === I welcome VSRE emails. Learn more at http://vsre.info/ === From: Greg Keogh Sent: Thursday, 30 October 2014 5:46 AM To: ozDotNet Folks, I've used SQLite in managed projects a few times over the previous years and it's always been a nightmare to get it working due to many overlapping issues: choosing versions and downloads or multiple components; interaction with Visual Studio versions and designer support; confusion and clashes of timing with different EF versions; getting config files exactly correct; the dreaded ADO.NET provider not registered and so on. I spent hours last night upgrading some old projects to use EF6 and the latest SQLite ADO provider 1.0.94 and the latest Nuget packages that support EF6. They've changed the format and names of things enough to make you relive all of the problems I mentioned above. For an hour I wondered why there was no designer and it kept add EF5, until I realised I had to move from ADO 1.0.90 to 1.0.94. After that there was SQLite provider in VS2013 and it took random shuffling of the DbProviderFactories section to get it working, then I didn't notice the slight spelling change of a provider and got not registered crashes. Overall it was stinking misery to upgrade due to lots of tiny gotchas. This is part of the reason of I've been casually searching for lightweight in-process really easy-to-use databases for the last year. I'm using ESENT and will look at Kitaro ISAM when I get a break, maybe even mongoDb (although it still depends upon a native C++ library). Greg K
Re: SQLite déjà vu again
Is it SQLite that is the nightmare, or ADO? You might do better running ODBC. Less layers, more independence.. On Thu, Oct 30, 2014 at 8:46 AM, Greg Keogh g...@mira.net wrote: Folks, I've used SQLite in managed projects a few times over the previous years and it's always been a nightmare to get it working due to many overlapping issues: choosing versions and downloads or multiple components; interaction with Visual Studio versions and designer support; confusion and clashes of timing with different EF versions; getting config files exactly correct; the dreaded ADO.NET provider not registered and so on. I spent hours last night upgrading some old projects to use EF6 and the latest SQLite ADO provider 1.0.94 and the latest Nuget packages that support EF6. They've changed the format and names of things enough to make you relive all of the problems I mentioned above. For an hour I wondered why there was no designer and it kept add EF5, until I realised I had to move from ADO 1.0.90 to 1.0.94. After that there was SQLite provider in VS2013 and it took random shuffling of the DbProviderFactories section to get it working, then I didn't notice the slight spelling change of a provider and got not registered crashes. Overall it was stinking misery to upgrade due to lots of tiny gotchas. This is part of the reason of I've been casually searching for lightweight in-process really easy-to-use databases for the last year. I'm using ESENT and will look at Kitaro ISAM when I get a break, maybe even mongoDb (although it still depends upon a native C++ library). *Greg K* -- Meski http://courteous.ly/aAOZcv Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough - Adam Hills
