I see that the IronRuby team has documented using ActiveRecord in IronRuby with MSSQL - they indicate that some adjustments were required to the adapter.
In interview on 8/11/2009, Jimmy indicates a major drawback of IronRuby:
The main limitation is that IronRuby does not support any
of the C-based Ruby libraries
That indicates that the SQLite-Ruby library that depends on sqlite.dll is probably out of the question. However, in the same interview, he says:
For the database you can use SQLServer Express (which is free),
or any .NET based database, like the recent csharp-sqlite port.
That sounds promising, but I'm a bit overwhelmed on how to begin! How do I go about connecting Ruby's ActiveRecord to csharp-sqlite or where can I look for more guidance?
I found some more write-up on IronRuby and SQLite, but I may need some translation help?
The current solution is to port do_sqlite3 to use all .NET APIs. There are a couple ports
of SQLite to .NET, but none are widely used yet. For 1.0 we will have an ironruby-dbi gem
for using .NET based databases through the Ruby DBI API; so using SQLExpress and
SQLServer will work with an appropriate sqlserver adapter. I'm not sure if there is a
do_sqlserver adapter yet for DataMapper, but we'll leave that to the community for doing.
Does this imply that my technology stack could go something like: ActiveRecord uses SQLiteRuby, SQLiteRuby is tweaked to use ironruby-dbi (should be little change since this is the Ruby DBI API??) then ironruby-dbi has the smarts to work with a .NET based database such as c#sqlite. Of course I will need an adaptor to go between ActiveRecord and SQLiteRuby ... hopefully no change required there?
Sugggestions, Advice, Tips?
you won't be able to use activerecord as is.
You can either wrap the ADO.NET provider for SQLite or you can perhaps help with the ironruby-dbi project and provide a dbi adapter that handles sqlite correctly. From then on adding it to rails is easy as it would require replacing the connection with the dbi connection.
It is a work in progress though and at this moment most efforts have been around sql server, but I too would like to get sqlite working properly on IronRuby with rails.
Another approach would be to change the active record adapter for sqlite to work with the ADO.NET provider (that would probably require the least effort but won't help outside the rails community). I have a pretty good idea of what needs to happen to make it all work but I simply don't have the time to do all of these things, unfortunately.
Have you tried using the SQLite adapter? It might work out-of-the-box.
I haven't tried it personally though.
Related
I'm having trouble getting a overview of the different SQLite libraries to be used with .Net Core and/or Standard.
It seems there are primarily two:
MS: Microsoft.EntityFrameworkCore.Sqlite
sqlite.org: System.Data.SQLite
Is the MS library completely independent of the sqlite.org's libraries? And if so, which one is recommended to use?
I prefer simplicity....it seems I just need two dll's if using sqlite.org.
There are two main SQLite packages for .NET Core/Standard. They are independent and use separate native binaries.
Microsoft.Data.Sqlite
System.Data.SQLite
The former is provided by Microsoft, the latter by SQLite.org. I prefer the Microsoft one but unless you're looking for specific functionality (SQLite.org's supports encryption, Microsoft's supports fts5, etc) either one will probably work fine. They both implement System.Data.Common and so the APIs are almost identical. SQLite.org's can load arbitrary extensions which Microsoft's cannot (though with the latest release it was looking like SQLite.org's couldn't load fts5 which I know worked with previous releases).
I would recommend using Entity Framework Core or another similar third-party database abstraction package unless you absolutely can't use modelling for some reason (EFCore still lets you run the occasional low level query if you need to). It's quicker to develop, and easier to maintain the code.
Microsoft.EntityFrameworkCore.Sqlite provides support for Sqlite in EFCore, using Microsoft.Data.Sqlite. So you would want to use that in this case. The internet says you can also use System.Data.SQLite but it looks like Microsoft.EntityFrameworkCore.Sqlite still tries to load the underlying native binary from Microsoft.Data.Sqlite for some purpose, though it does appear to use System.Data.SQLite for the actual database operations. Not sure exactly what's going on there.
Microsoft.EntityFrameworkCore.Sqlite is for Entity Framework Core ORM is more complete but heavier.
The System.Data.SQLite.Core can use with Dapper ORM SQLite and Dapper but I use the Microsoft.Data.Sqlite.Core with SQLitePCLRaw.bundle_e_sqlite3 and Dapper ORM, I think I had problems with System.Data.SQLite.Core.
Use without is hard and I not recommend.
I am programming a standalone application which needs a local database storage.
I have read about SQLite and it seems like it could perfectly fit my needs.
Nonetheless someone told me that SQLite is going to be discontinued. Is that true ? If so, what technology should I use instead ?
The SQLite documentation says:
The intent of the developers is to support SQLite through the year 2050.
The developers are working on a new major version, actually. Maybe whoever told you that heard about it and got confused thinking this means work on SQLite 3 is stopped (it isn't). But even if it were discontinued, the current version isn't going to disappear or stop working.
Is there any program that can serve as a GUI front end for SQLite3 database?
The general idea is to connect to the database remotely, and administer it in FileMaker-like GUI interface, where the online scripts would have a job of just presenting stuff.
I tried FileMaker with ODBC drivers, but have not been successful. SQLite3 is not directly supported, and I couldn't find another driver or software online. (Please mind that I am not talking about database editor software, but something that would be used as a database "CMS" if you will.)
Thanks!
Are you using a mac? Try the ODBC from Actual Technologies that will work for the most databases out there.
There is a more direct approach, that I like better because ODBC is not fast. For small amounts of data it's ok. Besides that communicating direct with the external database without to much middleware is in my opinion always better.
MBS has a very nice plugin, and supports a lot of SQL connections. It works really well and fast. Perhaps you should take a look. I use it a lot, as I've used ODBC a lot in the past.
I am exploring Zumero for a new project and attempting to understand which SQLite it works with. Mono.data.sqlite, System.data.sqlite, Sqlite-net, or Sqlite-net Extensions. I prefer to use the Extensions version however I suspect that it will not work with it or the Sqlite-net because I would be unable to define the tables using the modified Zumero syntax.
I do need to be able to sync multiple smart devices with themselves and with desktop. Any ideas would be helpful.
The current version of our Xamarin component supports (and includes) System.Data.SQLite.
As you suspect, the ORM-ish features of Sqlite-net (and its variants) are not yet supported because Zumero tables need to be created a bit differently than regular tables. We do plan to implement this functionality, but I cannot yet promise a specific availability date.
This is really a "pardon my ignorance" question so apologies if it doesn't meet the requirements.
I want to develop a fairly simple database application. It will be desktop based and lightweight so I'm happy that SQLite will suffice. I have also decided upon Qt and pyside.
Looking through the mass of tutorials out there, I keep coming across sqlalchemy and exlixir (and Camelot). I am basically just wondering what advantages there are to using sqlalchemy (and elixir) over basic QSql in Qt? What would I be missing if I didn't use such a thing.
I know this is basic but before I can progress on my self-tuition process, I just want to get this clear in my head.
Basically, you have 3 options here.
QtSql
QtSql is a separate module in Qt for working with SQL databases.
Pros:
Integration with Qt may be easier
Cons:
Hard to learn
Was made for C++, requires some redundant code
Requires adding one more Qt module to your project
Documentation looks bad
sqlite3 module
This a module in Python standard library to work with SQLite databases.
Pros:
Very easy to use
Code is quite concise
No external dependencies
Cons:
You do have to write SQL queries
SQLAlchemy ORM
SQLAlchemy makes work with databases similar to work with usual classes.
Pros:
Object Relational Mapper: exposes an object-oriented interface and makes SQL queries for you
Once you've set up the table information, work with databases is pure joy
Cons:
Steep learning curve
Here's my conclusion:
If you are comfortable with writing SQL queries and don't have to do a lot of work with databases, use sqlite3. And if you don't mind spending some time to learn something awesome, go for SQLAlchemy.
About the other projects you've mentioned:
Elixir seems dead, and SQLAlchemy has its functionality built-in now, probably better.
Camelot is just weird... I wouldn't use it.
I'm in a similar situation... fairly early in the PyQt learning curve, looking to work on some database-related projects. I've ran across some of what sound like the same threads that you have... they talk about sqlalchemy, elixir, or Project Camelot in conjunction with PyQt4. None of them really seem to go into much detail as far as explicit benefits, though. Apparently its assumed that the benefits are inherently obvious to the reader ;) For the most part... what I've gathered is that once you get to a certain level of complexity regarding your project, you'll most likely have more or less written some of the basic abstractions for database handling using the applicable Qt4 objects anyways and that you'd be money/time ahead to just use sqlalchemy/elixir rather than 'roll your own'. Camelot takes that a bit further yet, from what I can tell (as a green horn myself).
Here's what I've decided, for the near future: I plan to work my way thru the first few basic projects, using the DB stuff provided by PyQt. After I'm comfortable with that, then I may go back and rework things using sqlalchemy, elixir, etc.