We're considering migrating to TopLink 11g JPA from Oracle Kodo JDO. But I see that EclipseLink exists and appears to be, perhaps, better thank Toplink. The wiki article on it currently states
EclipseLink is based on the TopLink
product, which Oracle contributed the
source code from to create the
EclipseLink project. The original
contribution was from TopLink's 11g
code base, and the entire
code-base/feature set was contributed,
with only EJB 2 CMP and some minor
Oracle AS specific integration
removed. This differs from the TopLink
Essentials Glassfish contribution,
which did not include some key
enterprise features… EclipseLink is
the intended path forward for
persistence for Oracle and TopLink. It
is intended that the next major
release of Oracle TopLink will include
EclipseLink as well as the next major
release of Oracle AS.
Looking for which you would choose to use had you the option -- TopLink 11g or EclipseLink and why. One thing I experienced with Toplink 10 was that you were almost forced to use TopLink Workbench or JDeveloper to interact with the toplink configuraiton/to get object generation to work but even then, neither of the two tools provided access to all of the TopLink APIs via visual development, so you ended up with this cross-breed of some code generation with some custom coding (say you wanted to take advantage of some object metadata feature, you might have had to explicitly call an API to set the property you wanted).
We are a development team of about 20, use Eclipse as our IDE and run Ant builds. Thanks!
If you're moving to from JDO then I expect you're planning on migrating to EclipseLink JPA which has excellent tooling in Eclipse from the Dali project. EclipseLink is the JPA 2.0 reference implementation and also supports many advanced features and an extended JPA orm.xml mapping file for declaratively using those features.
BTW, Oracle TopLink 11g ships with EclipseLink as it's JPA implementation so technically TopLink JPA==EclipseLink JPA. :-)
Related
considering the latest version of Entity framework as against NHibernate, is there a reason why I should use NHibernate as opposed to the latest version of Entity framework?
Are there features of Nhibernate that is not covered by current version of Entity framework?
thanks
There are tons of posts about differences between NH and EF - do some yourselves research if you want to get complete answer.
Short version:
EF 4.1 brings only new way to use EF 4.0 - it means new simplified API called (DbContext) and code mapping. Both these new features are more limited than original EF 4.0.
EF 4.3 brings code-first migrations for incremental data model development.
EF 4.5 Beta / EF 5.0 Beta brings support for enums, spatial types, table valued functions, auto compiled queries + performance and API improvements.
There are a lot of NH's features which are still not possible in EF
More possibilities for complex mapping
Custom type mapping
Batch command execution
Future queries
2nd level cache
Extensibility and a lot of ready to use extensions
A lot of hooks where you can replace NH's default implementation with your own or add new logic
etc.
EF has better LINQ support and it is from MS - for many companies this is important decision point. You can check data user voice to see what features are currently requested from ADO.NET team for next releases.
I'm writing an application that manages something like Drupal's nodes. I'm planning on using the app in various content management systems / applications (Concrete5, Wordpress, custom Zend & Yii applications, etc...).
Since I'm using it in so many different places, I have to package an ORM with the app (ie I can't use Conrete5's or Yii's ORM, etc...). I love Doctrine 2, but am concerned that this is too 'big' of an orm to be packaged with my app.
It get's messy, for example, if I'm incorporating this app with a Zend application which is running Doctrine 2. I don't want two 'instances' of Doctrine running in the same app. Is this a warranted concern?
Question: Is Doctrine 2 too 'big' for this project? If so, what would be a good alternative ORM?
If you are going to use your application as an extension for other CMSes and/or frameworks,you should definitley use an ORM for the following reasons which comes to my mind:
1.CMS database installations are different.some use mysql some use oracle ,etc and you will have to create your own adapters or
2.Use CMS's native database abstraction layers.So you will have to rerwite your own model for every cms plugin you are gonna make.
3.Doctrine can do many big jobs but using doctrine is rather easy.doctrine is not resources intensive.
4.using more than one instance of doctrine will not be a problem as far as i know.
5.however doctrine2 requires minimum installation of PHP 5.3 and some shared servers might have older versions of php which this problem will be resolved while time passes and 5.2 becomes obsolete.
However in some CMSes more than one connection will made for your extension to work.(one for the CMS'S native database queries and one for your doctrine query.)
Way 1: work with different ORM's via adapters
(+) better integration with frameworks
(-) a lot of work to implement adapters
(-) loss of flexibility (limited by your adapters interface)
Way 2 (my choice): Use PDO with FETCH_CLASS, it's comfortable enough (you can fetch data to instances of your classes). Most of modern ORM's on PHP works through PDO, so integration must be easy.
Also about Doctrine 2 & Yii -- I tested this combination, works fine.
I have one project using NHibernate 1.2. I know it's old, but I've used it since I'm working off NHibernate in Action, which targets that same version.
I've been thinking I should update my understanding of the tool, as well as the tool itself. But I wonder what the differences are between versions. I know 2.1 has been current for some time, and that 3.0 is in the works.
What benefits or features are gained, lost, or changed when moving to NHibernate 2.1 or 3.0?
Off the top of my head and mixing 2.X and 3.0 features... LINQ support, EventListeners (more powerful Interceptors), System.Transaction support, generics support, multiquery, future queries, SchemaUpdate (rather than just SchemaExport), much better HQL parser, ... Plus numerous bug fixes. A lot has been going on in the NHibernate world since NH 1.2...
With the 3.0.0 release, NHibernate
includes support for LINQ, along with
additional features such as:
Along with a long list of bug fixes
and improvements, it has several new
features including
A new strongly
typed criteria API called QueryOver
Lazy loading of columns
Alias delimiting in generated SQL
Support for DetachedCriteria within
IStatelessSession.
Improved support for LINQ, overcoming the HQL limitations of the previous provider.
Breaking change:
Upgrading users should be aware that
one of the fixes means that null
values in dictionaries are no longer
silently ignored, which has the
potential to break existing
application code.
James Kovacs summarized it pretty well, but for a complete list of changes check https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/releasenotes.txt
It contains every single bug/improvement/new feature for all NH releases.
You get Linq support!
I started on 2.x+ so I can't say much...but I'll for sure upgrade to 3.0 once it's out of beta. Mainly because QueryOver looks like ICriteria on type safe steriods!
v3: Removal of the dependency on log4Net (which is often a love-it or hate-it thing)
is anyone building the truck NHibernate and FluentNhibernate together? How's it working? are you using it for production systems?
How is the Linq support?
Is it nearly ready for release?
Is there a nice and concise way to keep up to date with what is going on in the world of NHibernate? (ie, without having to read lots of blogs, and mailing lists )
You can find trunk FNH builds here: http://hornget.net/packages/orm/fluentnhibernate/fluentnhibernate-trunk (I haven't tried it as I don't use Fluent)
NHibernate 3.0 is pretty stable and the new Linq provider is very good, with an excelent coverage of the possible Linq constructs and clever, non-intrusive support of NHibernate specific concerns (caching, fetching)
I'd use it in production without much concern; being in a "pre-alpha" state only reflects the seriousness of the project team, as the current state is more similar to that of a Visual Studio RC than a CTP or Beta.
Update (2010-12-05): NHibernate 3 was released yesterday.
Directly on FNH site, under the download section, you can find the "Latest Master Build"
http://fluentnhibernate.org/downloads
If it may help
My development group uses Visual Source Safe for version control; this choice was originally made due to cost and its tight integration with Visual Studio.
As our repository has grown Source Safe has really started to show its limitations and we are considering moving to another solution. Up for discussion are Team Foundation Server, Subversion, Git, and Mercurial.
We are largely a data shop, so another major factor for us is being able to easily version SQL Server 2005/2008 projects. This is one of the benefits of using Source Safe, and also of Team Foundation Server - the integration with Microsoft SQL Server Management Studio.
I'm wondering if anyone has had experience versioning SQL Server with Subversion, Git, or Mercurial and can provide some solid pros/cons for each of these systems, as well as how you went about implementing them.
My honest answer is don't do any integration with your database tooling and SCM if you can avoid it. Use the filesystem where possible. It's another layer of integration which is going to be a pain. Small separate tools are better than a behemoth.
We use Subversion and SQL 2005 together in the following manor:
We use TortoiseSVN only. No VS/SSMS integration at all.
We have a principle of "automate everything", so we never rely on GUI tools to do work.
We keep all scripts inside SVN along with the code. The code, schema and scripts are versioned together.
Schema changes are numbered in order of application i.e. 000-create-table-users.sql. We write down the maximum script number deployed in each environment. Each script performs a migration to the next database r number. When we deploy, we check out the source and run all scripts from the last version number to the highest number.
Any non-schema scripts (sprocs/views) are idempotent (can be executed any number of times with the same result). They are applied via a nant plugin we wrote. These are replaced every time we deploy. Don't forget to refresh your views!
We avoid any scripts where possible anyway as we use NHibernate so there are less problems with script versioning anyway.
From this structure, we can re-create the environment and database at any point in time on any machine which is important.
We do NOT use it for unit testing however - we rely on the NHibernate schema generation to do this on top of an SQLite database.
The only negative point we've encountered has been making sure that developers adhere to the process. Herding cats is a very appropriate description.
Visual Studio Team System 2008 Database Edition (codename "DataDude") is what you need.
It allows you to version your database objects in ways that will blow your mind. (eg upgrade a customer site to a specific version, or rollback to a previous version without destroying any data).
Check out the features at Gert Drapers' blog, starting with this post.
Or if you prefer a podcast, listen to DotNetRocks with Chris Sells in show 494.
I don't know whether you're limited to TFS for source control, when using DataDude -- but it is the undeservedly "underhyped" member of the Visual Studio family.
This might be a useful tool for you:
http://www.liquibase.org/
It's designed so that it's easy to version control in any system, and manages your upgrade scripts in a sane way.
Git and Mercurial are the only ones you should consider IMHO, the other 2 are too old-fashioned. Modern SCMs should treat branches like git does.
For git vs. mercurial comparisons see:
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/, http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn.
I have no past experience with SSMS SCM integration though, but AFAIK neither of the systems mentioned (except from TFS) have one. I wouldn't call it a disadvantage tho - git GUI for example is a pretty handy tool, which you'll find more enjoyable than such an integration. This is at least my case when moving from SVN (with VS integration using Ankh) to Git (with no integration at all)...
Mercurial has VS integration with VisualHG, if you think DVCS is the way to go. We use that for C++/C# projects in our shop, and it works well enough. (OTOH, I've never used any "full" integration, so I'm happy to work with the explorer extension and/or command-line for detailed VC work.)
We've now added VSS support to SQL Source Control, which integrates with SSMS to provide fully integrated source control for database development. To try this out, please visit:
http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265
TFS is missing a few features of VSS, notably keyword expansion. If you don't embed revision keyword info within your source files, then it should not be a concern.
There are potentially quite a number of alternatives - SQL Server Management Studio (SSMS) supports integration with any Microsoft Source Code Control Interface MSSCCI Provider. So you can broaden the search to source control systems that feature an MSSCCI compatible provider.
In SSMS, Check out Tools -> Options -> Source Control to see what provider plug-ins are installed on your system.
For example, Team Foundation Server's integration with SQL Management Studio is courtesy of the TFS MSSCCI Provider. I think there's a provider for CVS/Subversion ("Aigenta Unified SCC") and so on.
As to a pros/cons list, I think provided there's a compatible provider, you can open the question up to a wider audience. My main experience is with VSS, TFS and Subversion. It really comes down to your team, and environment. Can you elaborate more on your environment?
E.g.
would you be interested in establishing CI (continuous integration)?
automated builds/automated versioning?
support for multiple environments?
configuration management?
what team size do you have? likely to have lots of merges/branching etc?
do you have a bug tracking system in place already (you get work items/bug tracking as part of a TFS roll out)?