Does anyone know which latest scala version SORM supports? Also is the development of SORM ongoing? Finally, Are there any plans to support noSQL databases or as the name implies, is it only for relational databases?
SORM supports the whole 2.10.* Scala branch.
Development is ongoing but isn't very fast. With the release of version 0.4 SORM will be hugely refactored and modularized towards much easier third-party driver development. I expect this to draw in a more substantial contribution to the project.
SORM's APIs are getting changed to get free from chains of relational drivers and to generalize with future NoSQL drivers implementations in mind. Though I must admit that no specific implementations of NoSQL drivers are planned for the 0.4.0 release, but it's planned to work on a CouchDB support after this release.
Yeah, with these plans the framework's title seems to become quite confusing, but it's the issue with the least priority right now.
Related
I am interested in using OrientDB with the Ferma alternative to Tinkerpop2 Frames in a very large project, but I have had some concerns since Tinkerpop2 is no longer under active development. Tinkerpop3 is wholly uninteresting to me as it lacks the features I want (Blueprints, Frames or a Frames alternative like Ferma), it is too immature for enterprise-scale projects, and there are concerns about its performance.
On the Ferma Google Groups mailing list, the opinion was that Tinkerpop2 is unlikely to go away anytime soon (probably not in years) due to its widespread implementation in existing projects and the current state of Tinkerpop3.
I would like to hear the opinion of OrientDB developers and users on whether it still makes sense to base an enterprise scale project on Tinkerpop2 at this point in time. I believe I read in an earlier post that OrientDB plans on supporting Tinkerpop2 Blueprints as their graph API for at least 3 more releases (does this mean major or point releases?), is this correct? Ferma developers say that if Tinkerpop3 ever reaches a maturity and performance level comparable to Tinkerpop2, it will be ported.
From a practical perspective, OrientDB and Tinkerpop2 with Ferma definitely seems like our best choice, but we can't afford to lock ourselves into a technology that might have to be replaced anytime soon.
OrientDB will provide support for TinkerPop 3 in v3.0, so mid 2016. Today we have thousands of users and hundreds of clients that are running with current Graph API that is based on TinkerPop Blueprints 2.6. This means that the support for TP Blueprints 2.6 will be available for long time.
I am the developer for Ferma. I just want to say we actively support both TinkerPop2 and TinkerPop3. As long as you implement your interfaces using the annotation method rather than with the gremlin pipeline then you should be able to move between TinkerPop2 and TinkerPop3 seamlessly. You may want to consider just sticking with Ferma and when/if TinkerPop2 is no longer actively supported just swipe it out for TinkerPop3.
When Linq-to-Sql was first released, I used it quite a lot for small and medium sized projects where a true multi-tier architecture wasn't required.
NHibernate, Small Middleware, Overkill
Where I work, we now almost exclusively use NHibernate for true Domain Driven development.
I'm working on a small temporary (a lifetime of probably a year, maybe less) middleware component where NHibernate feels slightly overkill in terms of configuration and keeping the entities up to date. Especially because I haven't got any control over the DB, it sometimes changes, and it's a little bit "legacy".
Some changes were recently made to the DB, and the NHibernate mappings are not very complete.
Linq-to-Sql? Or EF?
I thought it might be easier just to rip out the IRepository implementation I have and replace it with a Linq-to-Sql implementation. Then I can just use lambdas for my simple queries, and just drag and drop the tables in.
RAD But Dead?
In this scenario the RAD elements of Linq-to-Sql make sense. But it's essentially old technology. Should I not use it? I've never used the Entity Framework. Should I use that, is it as easy and quick to use?
cheers
Is it still OK to use Linq-to-sql?
Yes. It is OK to use any technology which allows you delivering the product in time, with required functionality and quality. You can still find projects using ASP, ADO, VB6. One reason why Microsoft technologies have very hard time in many international corporations is that their products have very short lifetime. Linq-to-sql was on the market less then 2 years and was deprecated by Microsoft but companies / community argued about that and Microsoft changed their strategy little bit. Linq-to-sql doesn't have new features but it is still supported and a fully functional technology.
Will Linq-to-sql or EF solve your problems?
It depends. Perhaps yes and perhaps no. Don't believe to marketing announcements about RAD. Sometimes I feel that people think that RAD is about designer. No. Tools supporting RAD are about well defined API which is easy to understand, easy to use and doesn't contain unexpected behavior (Principle of least surprise) - you will use the API to quickly prototype the application but it still requires understanding and practice. NHibernate's mapping is still prototyping when you compare it with manually doing whole data access. We can even follow the basic rule of good framework: Easy things are easy to do and hard things are possible. That is something that NHibernate accomplish much better then EF or Linq-to-sql.
If you know NHibernate but you don't have any real world experience with EF or Linq-to-sql, you can be sure that neither Linq-to-sql or EF will increase your productivity in first one or two projects where you use it. If you don't have too much experience with NHibernate changing to EF or Linq-to-sql will probably don't cause temporary lose of productivity.
I also don't think that EF or Linq-to-sql will generally help you in situations where database changes. As I remember Linq-to-sql designer doesn't have update mapping functionality at all and because of that it is very often used completely without designer so you must still manually modify mapping. EF's updating model from database can be helpful here but it is not a silver bullet. Some updates can require manual modification of EDMX file (huge XML).
At last be aware that NHibernate's mapping features are much more powerful especially when working with legacy databases. Linq-to-sql's mapping features are very limited, it is mostly 1:1 mapping of tables to classes with some exceptions (basic TPH inheritance). EF offers more complex mapping features but it somehow expects a correct design of the database.
If you (and your coworkers) are comfortable with NHibernate, then it should be just as RAD as Linq to SQL. There's no reason not to use L2S as long as you understand it's not going to get much in the way of updates and improvements from Microsoft, but in my experience if you know how to use both frameworks already, no need in re-doing the work just because L2S might be a little more RAD
Some good discussion on NHibernate vs L2S/EF
Entity Framework vs LINQ to SQL
MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)
in your specific case, you should go with technology you are most comfortable with. Though Linq2Sql is relatively straight forward - and build right into the language - it does have a slight learning curve and its own set of gotchas!
For a project I'm using both Scala and Riak (two things I have never worked with before ;) ).
Google searches seem to suggest using Riakki. However, it seems like that particular library hasn't been maintained since 2009 and doesn't even compile on my system. There is a more up-to-date fork on GitHub that does seem to work with more recent Scala versions. But Riakki seems to depend on Jiak, which has been deprecated since february of last year.
Seems like the only reasonable choice would be to use the official Riak Java-library from Scala. That's certainly possible, but I'd like to do things the Scala-way as I'm trying to learn the language. Having to interface with a Java-style API might ruin a bit of the fun. Writing my own wrapper sounds like it will be too much work.
tl;dr: I want to use Riak from Scala. What are other people using?
edit: just found Ryu (can't link to it - annoying limit on amount of hyperlinks per question for new users). Doesn't seem all that mature though.
Stackmob recently opensourced Scalariak.
Scaliak is a scala-ified version of the High-Level Riak Java Client w/
a Functional Twist. It is currently being used in production at
StackMob.
Scaliak is currently feature incomplete vs. the original High-Level
Riak Java Client. What is currently supported are mostly features
being used in production (there have been a few features implemented
and subsequently not used).
There is also Raiku which states that it is async.
I'm in the same bucket - excuse the bad pun - although I have some experience with Scala. I'm thinking of using the official Java client.
When you are toiling up a steep learning curve, you don't need to be dealing with incomplete and potentially wobbly API's. In my experience, using Java API's from Scala is minimally painful.
I think there'll be enough delight in playing with our new Raik toy that we'll forget about whatever un-Scala-ish foibles the Java API inflicts upon us. All the best.
I'm the author of yet another Scala Riak client, simply called riak-scala-client. It is based on Akka and Spray, it is not built on top of the existing Java client, and most importantly it is completely non-blocking.
Check it out at http://riak.scalapenos.com and let me know what you think.
I'm currently testing Lucene.Net, and it's perfect for my needs but I've seen this recent post in the dev mailing list (with no answers)...
Do you think it's unsafe to start developping with this library ?
I thought it was widespread used ?
As far as I know Lucene.NET is used for RavenDB, so it should be in pretty good shape.
Also, it depends on what do you mean by "unsafe". It is hard to guarantee any OSS project will never stop, so all of them are inherently "unsafe". Same is actually true for commercial projects.
Lucene.NET seems to be a reliable project at current point (I used it in small project, so I can not guarantee that, but RavenDB seems to do just fine), so even if new development stops, it should still be possible to rely on it.
I think it all depends on longevity of your project, on your readiness to fix any issues in Lucene (if they arise), and on requirements of the project owners.
I have been sold on the fun of using linq in areas other than pure database interaction. (See Calling fellow code nerds - Alternatives to Nested Loops?).
We are stuck on 2.0. I have told the powers that be about the ease of updating to 3.5 (we have already migrated to VS2008) but they are wanting a list of "benefits" for upgrading.
Can those that have experience in 3.5 help provide some talking points for the benefits of updating an existing app to 3.5?
UPDATE: Found an additional reason: Microsoft's inclusion of Charting tools for Asp.Net as a patch on top of 3.5! They get their business value, I get the fun...
Can YOU make a case for it? Sounds like you want it because LINQ is fun. Other people are mentioning features that are fun. I've always had a problem selling fun features to management because they aren't very compelling reasons to potentially disrupt an environment.
Honestly, it really depends on what you are using C# for. Are you a web developer, system admin, something else? Taking a general approach, I would use the following selling points (you will need to do some work to prove these things):
Zero-disruption for end-users when upgrading. Upgrading to the new version will be seamless and we will have a thoroughly reviewed test plan for updating all clients to this version. All of our old applications that require .NET 1.x or .NET 2.0 will still work perfectly.
Programmer Efficiency. You could mention how more of the Windows API is wrapped by .NET classes, thus making programmer more efficient because they don't have to P/Invoke as much. LINQ makes your more productive because of x, y, and z. Lambda expressions make you more productive because of x, y, and z.
Ease pains of future OS migration. Moving to WPF now will prepare us for Vista/Windows 7. We won't have to migrate applications using the now deprecated "Windows Forms" to WPF, because we will already be using it.
More applications purchased from 3rd parties will require it, so we will have to upgrade sooner or later.
In the end, you need to prove that at the very least, this move will not cost you money in terms of increased support or testing costs. If you can show it will make you be more productive and it will be a rather painless switch, then you will get your wish.
Maybe you should talk to some Java developers who are probably still forced to develop using 1.3 or 1.4 despite 1.5 being out for over 3 years and 1.6 for a couple... it appears platform consistency across the business is often of greater importance than the benefits of using the latest and greatest.
Also remember that 3.5 is just additional BCL libraries. You are still running on CLR 2.0. Same is true for 3.0. Usually when people find out that the underlying framework is the same and that you are just adding in new libraries they are more likely to go along with it.
You don't need .NET 3.5 to get LINQ or C# 3.0 features. You can implement your own LINQ for .NET 2.0. I am using C# 3.0 all over the place in my .NET 2.0 application. I don't know the full details on how to start the conversion process because I didn't set it up myself. This might be a good link for you: http://www.danielmoth.com/Blog/2007/05/using-c-30-from-net-20.html.
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Transitioning onto 3.5 would help you reap the benefits/ features of:
LINQ to (Entities/ XML / Objects / Datasets etc ).
WCF, WF and WPF.
ASP.net MVC where MVC is kind of a de facto standard in other
platforms like Ruby/Python which
allow you pure HTML/ Javacript based
development.
ORM options with ADO.net Entity
Framework/ Linq to Sql
4.
With a few addons you can have
support for dynamic languages
like
IronPython/IronRuby.
Oh ya I almost forgot ADO.net Data Services..one of my fav.
These are the few benefits that immediately come to my mind.
In my experience, the addition of LINQ and Extension methods alone have made many previously arduous and/or time consuming tasks much easier and faster. The increased developer productivity from that alone is worth the upgrade effort IMHO.
Lambda expressions are awesome. There is no end to the places where I find that lambda expressions help me out in a very concise and readable way.
Automatic properties, while being a simple concept, really help making the code base smaller and clearer.
Also, I sencond the extension methods.
Before I even opened this question I had my answer: LINQ - it's one of the greatest extensions ever in .NET - I love it. It took me a few days to figure out, but now I've got it, I use it all over the place. The ability to query collections and arrays is worth the upgrade alone in my mind.
Decreased development time (and therefore increased ROI)
Less time wasted finding workarounds for .NET bugs that've been fixed in newer releases.
Extension methods for native types (in a similar fashion to JavaScript prototyping)
LINQ extensions - they take a couple of days to get your head around, but it's awesome!
LINQ to XML makes working with XML so much simpler
LINQ to objects/collections
A nice new 3.5 poster from Microsoft that you can pin up in your cubicle.
As a manager if I have a happier more productive team that is producing more in less time, then its a no brainer.
Ask yourself this: Will the developers be more effective and will their increased productivity actually increase benefit to the company or reduce corporate costs once you've considered the upgrade/transition/installation on the servers/additional testing etc? If the answer is truly yes, then do the upgrade and quit arguing about it.