InfoQ: Q&A with Jiri Cincura of the Firebird Database Project about the ADO.NET provider , ORM ,EF …
Jiri Cincura was recently interviewed for InfoQ article – Q&A with Jiri Cincura of the Firebird Database Project. We touched Firebird, ADO.NET, O/RMs, Entity Framework etc. If you have any questions, feel free to ask.
Update: The article seems to be retracted for the moment , Don’t panic we asked why and investigate the cause (see the comments section) ,
Here is the full text from Google cache
We recently spoke with Jiri Cincura of the Firebird database project.
InfoQ: Can you tell us briefly about yourself and your role in creating the ADO.NET provider for Firebird?
Jiri: Currently I’m project lead for the ADO.NET provider for Firebird project. And actually only one active right now. I’m doing majority of development (although there are some worth contributions) and all the stuff around, like testing, releases, issue tracker watching, replying in mailing list etc.
InfoQ: And for the benefit of our readers who are unfamiliar with it, who would you describe Firebird?
Jiri: Firebird is a fully featured RDBMS, with small footprint and zero maintenance. It supports all standard features you’d expect – stored procedures, triggers, views, UDFs, monitoring, online (remote) backup/restore etc. There’s also so called Embedded version, that just one main DLL and few supporting it, without install or need to copy something somewhere. You’ll just reference this DLL and you have all the features of standalone (network) Firebird in your application. And of course, whole Firebird is completely free (and open source).
InfoQ: In the SQL Server world we have to deal with a serious trade-off. If you choose to use the embedded version, SQL Server Compact, then you lose the ability to use a lot of features. Is there any sort of tradeoff like that for Firebird or do you really get access to the whole feature set either way?
Jiri: Absolutely not. Firebird Embedded is fully featured as “big” server. It’s even built from same sources, only with different output (DLL file). You can use everything Firebird offers. And not only that. Migration is super easy. You’ll just take the database file and put it to some place where server can access it and you’re done.
InfoQ: So what’s involved in writing a ADO.NET provider?
Jiri: It’s actually pretty simple. You’re fixing bug, moving with features as Firebird server moves further and improving stability and code itself. Cleanup, refactoring. With all that you’re trying to keep backward compatibility and not introduce some breaking changes. And on the other hand you’re moving along with .NET and ADO.NET (i.e. Entity Framework) world and other data access providers and components.
InfoQ: DId you also work on the Entity Framework provider? If so, what’s your opinion of the ORM?
Jiri: Yes I did. I worker on provider since early versions around 2007. I believe Firebird was first 3rd party ADO.NET provider to have working Entity Framework support (and it’s open source). I think Entity Framework is good ORM, comparable to others, like LLBLGen Pro or NHibernate. It’s not here that long but still very good. I don’t think anybody can say i.e. NHibernate is best because … Every project needs something more and something less. And every ORM (including Entity Framework) has strong points and places where there’s room for improvement.
InfoQ: What areas in particular do you think the .NET-based ORMs need to improve upon?
Jiri: There’s mismatch between relational world and OOP world, even if you believe ORMs are hiding it, it’s there. For simple small applications, this is not a problem. But for a big applications, the ORM needs to be flexible enough to allow really experienced developer hook in and in rare cases when performance is critical or special needs are placed in front of him/her allow to do it own way without creating huge disruption in your code.
InfoQ: If you had more resources available to you (i..e. developers, hardware, etc), what would you like to do with Firebird and .NET that you can’t do right now?
Jiri: Provide more seamless experience for .NET developers using Firebird and improve codebase. Move further faster and provide more features, both from Firebird world and (ADO).NET world.
There is now support for the Firebird RDBMS in the most popular ORM for
Perl, DBIx::Class, as of version 0.08121 .
Using the ODBC driver with DBD::ODBC is recommended.
There is also support for DBIx::Class::Schema::Loader, which is used to
dump schema definitions, as of version 0.06000 .
This ORM is often used with the Catalyst web framework:
Here is the announcement and list of changes
I spotted his interesting projects or forks on github
ED:i saw that you forked fb ruby library could you tell me a few notes on how you use it in sequel orm i want to add an post on firebirdnews.org if you want so also an small intro would be nice
wishdev said :
I basically just wrote an adapter for Sequel which uses the Fb driver to work with Firebird. The fork was necessary mostly to fix an issue with using the RETURNING clause to get back sequence generated primary keys.
As for any intro with respect to myself – I’m the type that keeps his head down in the gopher hole for the most part. I didn’t do a huge amount of work because the Sequel ORM is so well written it was easy to build a Firebird driver.
If you need/want any more info please feel free to ask 🙂
John W Higgins
The first official release of the 0.5 series is now available. This version packs a huge amount of change since 0.4 including multiple paradigm shifts in usage as well as countless bugfixes and behavioral and speed improvements. Through a series of prereleases, 0.5 is already on production systems and has been extensively tested by dozens of users. With the first 0.5 release, 0.6 is underway as well and will be where Py3k support is targeted. SQLAlchemy 0.5 is available for download on the download page. A comprehensive migration document is at 05Migration.
There is at least one firebird-specific change:
- Added support for returning values from inserts (2.0+ only), updates and deletes (2.1+ only).
Released 1 Dec 2008.
- A number of changes ported from SQLObject 0.9.8.