Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm seeking for a good ORM for postgres under Node.js, one that supports declaration of relationships beetween models, and fields validation. I've searched during a long time and cannot get any satisfying results. Maybe someone can point me to a project I missed during my researches.
Thx.
node-orm2 looks good: supports association, validators, and mysql, postgres, and mongo (in beta)
UPDATE: The node-orm2 package is no longer maintained. Possible alternatives include bookshelf or sequelize.
SequelizeJS - models, validation and migrations
BookshelfJS - a promise based ORM looks quite promising
JugglingDB - multidatabase ORM inspired by activerecord and datamapper. Supports validations, hooks, relations. Works with: mysql, postgres, sqlite, memory, redis, mongodb, neo4j.
Not production ready now (march 2012), but growing fast. I plan stable release soon.
Would recommend trying Knex for the database and Bookshelf as an ORM on top of it (developed by same person). I'm using it with postgres, but supports SQLite, MySQL/MariaDB and Oracle (in alpha) too.
Very expressive promise-based API with bluebird behind it, knex has a well documented and great command line tool for making migrations, seed files etc. Bookshelf uses backbone models and collections as an inspiration, including the .extend(..) paradigm for inheritance, so picking it up is a breeze if you come from that world. So far, so good.
Missy is a universal ORM for both SQL and NoSQL databases which is simple, flexible, well-documented and supports some fancy features that other ORMs are lacking
ORM's are a little too slow for fast nature of node.js; plain database driver is fine, but a little tiring. That's for I do write something just between: prego. It provides automatic statement preparation, migrations, simple models with associations, transactions and few utilities, all callback style and fast. Ideas/issues are welcome.
I suggest you use this pair: pg (like a driver) and light-orm (like orm wrapper).
https://npmjs.org/package/pg
https://npmjs.org/package/light-orm
https://www.npmjs.org/package/rdb
Simple, flexible mapper.
Transaction with commit and rollback.
Persistence ignorance - no need for explicit saving, everything is handled by transaction.
Eager or lazy loading.
Based on promises.
Well documented by (running) examples.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
We are in the process of getting our feet wet with Cassandra. None of us have any experience with this particular platform, but are experienced developers with JavaEE, JPA, etc. I came across the Kundera library that provides a JPA implementation compatible with several NoSQL datastores, including Cassandra.
It's tempting to go down this route, as we will be able to get up and running MUCH faster. However, is it the right idea? What are the tradeoffs of using a library like this? How does it affect performance? Is there a huge difference?
I'm curious to know what experiences others have had using this library. And, if there is something else we should look at instead I'd love to hear about it.
Taking Jonathan's (jbellis) to the next level, IMHO, the purpose of ORMs like hibernate or JPA specs is to hide the complexities of SQL since Application developers deal best in objects and not SQL.
Similarly, kundera hides the complexities of NoSQL but in an intelligent way that allows it to use the power of NoSQL but still make it easy for developers to use the traditional RDBMS paradigm.
However, as Jonathan mentions, you should still understand Cassandra data modeling concepts, otherwise, you will end up creating another SQL like monster even over Cassandra.
Kundera does help in this NoSQL modeling by using optimization techniques such as Embedded or One-to-Many relationships automatically converted into multiple Columns rather than creating new Columnfamilies (RDBMS tables equivalents) thus circumventing creating a physical relational model.
"A tool is only as good as the skills of the craftsman/woman using it!"
Use the native CQL driver and read the documentation on data modeling. Pretending that Cassandra is a relational database the way Kundera does is a great way to paint yourself into a corner without quite understanding how you got there.
PlayOrm is a noSql mapping layer and is NOT JPA compliant on purpose following many of the patterns of noSQL. noSQL is not relational. In fact, it probably should not have the R in PlayORM as it is not really relational completely either. You still have relationships in noSQL though. It is not just an RDBMS.
There are plenty of questions on here that ask 'what ORM should I use with x and y' but I didn't see any that specifically asked how to pick one. Related: Why should you use an ORM?, What ORM should I use for a ASP.Net MVC project?, Are there good reasons not to use an ORM? and more.
There are a lot of ORMs out there in the world. I'd like to get an idea of how to compare them. I've heard about things like active record model and domain model among others and I'm not sure what those mean. So what are a good set of criteria I can use to compare one ORM to another?
Our environment, in case you're wondering, is C#, MVC, SQL Server.
(I tried to answer in a non-.NET specific way when possible.)
The most important criteria for choosing an ORM are your business requirements.
I would say another important criteria is your belief in the future sustainability of the ORM. Microsoft has a tendency to change their data access technology every two years or so, so I would say Entity Framework's future is unclear. NHibernate may follow the same path as NUnit - when Microsoft released MSTest, NUnit languished for a while, but now NUnit has momentum again since Microsoft is mostly neglecting MSTest. You have to reach your own conclusion here, right now Microsoft appears to be giving Entity Framework some love, yet as far as I know it still doesn't handle enums very well and I haven't heard when that may change.
Another criteria is whether you have a preference between open source technologies or technologies from Microsoft or commercial third party technologies.
At some point, the features of the ORM will matter. You may need to prototype your scenario with multiple ORMs to determine if the features (and/or performance) of the ORM match your requirements. NHibernate is the most feature rich ORM in the .NET space.
Do you need to support a certain database vendor? Pick an ORM that supports the one you care about. SQL Server is the most widely supported database vendor in the .NET world.
Do you have a preference between code first or database first design? Pick an ORM that supports the one you care about.
Do you have a preference between active record vs. repository vs. something else? Pick an ORM that supports the one you care about.
I answered the question linked below about choosing a .NET ORM partially by providing links to all the times people asked which .NET ORM they should use on StackOverflow. There is a lot of value that can be gained from reading those other answers.
NHibernate, Entity Framework, active records or linq2sql
There is no one right answer nor one correct set of criteria for choosing. Your business requirements are the most important ingredient to consider.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am going to use a legacy DB2 on zOS as database in a banking project. I am proficient in programming on Oracle. Also I've used MySQL and SQL Server for many years but know nothing about DB2 and their SQL dialect and procedural language for writing stored procedures and functions.
I am looking for good resources to learn DB2 architecture + SQL dialect and their procedural language.
Thank you very much
Assuming you don't have a z10 EC and licences to use DB2/z at home, first step is to get DB2/LUW (the Linux/Unix/Windows version). The Express edition is here.
Then head on over to publib, the first site anyone should go to for IBM product related information.
And the Redbooks are another very good source of information. IBM employees frequently get time off to do these (I say "time off" but it's actually very gruelling, believe me).
As for the mainframe product, it's not always an exact match for LUW but it is close. Stored procedures can be written in any of the languages available on the mainframe (we mostly use REXX) and I think you can also use all the UNIX (USS) toolchain as well if you'd prefer bash, Perl and tools you may be more familiar with.
There is a bunch of information on the DB2 Infocenters hosted at IBM. The Infocenter pages are version specific, here is a link to an Infocenter including information on DB2 UDB for z/OS v8 and DB2 v9.1 for z/OS:
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2.doc/db2prodhome.htm
You can find a lot of reference in IBM redbooks; See for exemple this url (sorry in french) for some links to IBM sites (DB2 centric)
You will already know the basic principles of tables and sql from ORACLE.
There are numerous annoying differences in SQL function names and some keywords but that shouldnt slow you down too much.
Internally DB2 is vastly different from ORACLE especially in the way storage is allocated and the way locking and transactions are implemented. This should not bother you too much unless thay expect you to do some intense performance and tuning work.
The main areas of difference are specific to z/OS rather than DB2. Firstly most mainframe programs are written in COBOL or DB2 to run inside either CICS or IMS transaction monitors (think J2EE containers but for COBOL) and usually these programs use "STATIC" sql. So its definately worth reading the manual on how staic sql programs are written and implemented. The programming is actually easier as the precompiler does most of the hard work and delivers the data to actual fields in your program, but, there is extra messing around woth DBRMs, basiclilly the SQL is stripped from the source code and stored in a file, before you run a program the file must be loaded into the target database (using BIND PLAN ) and at this point the optimisation and access plan is done so when you come to run your program there is an access plan ready built and waiting.
The second major pain is you will need to learn JCL. Which is a pretty unique hangover from the very first 360 series circa 1968. Think of it as a very primative ant script!
FREE Book- Getting Started with DB2 Express-C
Find out what DB2 Express-C is all about
Understand DB2 architecture, tools, security
Learn how to administer DB2 databases
Write SQL, XQuery, stored procedures
Develop database applications for DB2
Practice using hands-on exercises
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
There are a number of framework out there that provide the skeleton for building applications such as CSLA, XAF, SCSF, ...
Do you use one yourself or do you build from scratch?
.NET is my favorite framework.
The applications I work on are usually too complex to fit into a "skeleton". However when working on Winforms, I like to take advantage of CAB for the UI. I wouldn't say this is the skeleton, but more or less the ground work for which the skeleton can be built, then the meat can be built upon it. I also like using a MVC for connecting the UI to the Data Layer. The Data Layer is typically LLBLGen or nHibernate.
For generating your skeleton for web applications, the ASP.NET Dynamic Data framework looks really promising.
I just use my own class library, which handles things like SQL (differences between different engines), provides lots of custom data structures and types, IoC/Dependency injection, etc.
I have been using the XPO-library from DevExpress before but after having some rather largish performance problems with it I'm back to plain SQL.
I have never used a bigger framework like those you mention. Earlier experience with those have always led me to believe they're powerful, but also restricting. You usually end up combating the way they do things to implement more complex features.
I used CSLA.NET to build an large LOB Windows application (title insurance) in 2007, basically it is a framework that you build your business objects based on. The business objects are generated from database tables with predefined templates. SPs are mostly utilized for data access. Personally I've not liked it because there are lots of code and template need to maintain, I prefer ORM to template based approach.
I've been using XAF to build another Windows based HR application, it can help you create a complete application just in 15 minutes with nice UI and lots of cool stuffs such at localization, customization, skinable and so on. But the big problems with XAF are limitation of the underlying XPO, and not so good performance.
I was listening to a podcast recently that was discussing at length the short comings of Entity Framework (EF).
But, their opinions may need to be taken with a grain of salt (by me), as from what I could gather:
These were folks that were ORM experts.
They either made their living off of ORM tools, or their hobby
They were using ORM tools for large scale applications
They were also very concerned with the uber-tactics of ALT.NET that I'm not necessarily concerned with (YET)
My overall question is:
For what type of project is Entity Framework currently suited?
But here are a few sub-questions that may help you get where I'm headed with that question:
Is EF better than nothing? I'm tired of doing everything by hand.
Does it come close to "solving the same problem" as LINQ to SQL? 2a. If yes, when would one be suited over the other? * found a thread on this question as I was going over questions with this tag, so nevermind *
Does it lend itself to simple 'quick and dirty' applications, such as when the bulk of your administrative CRUD forms?
edit: for those that might be curious, I am mostly working on small to medium sized applications. That can guide your response, or not.
The Entity Framework is suitable for all applications which would benefit from having an ORM layer. Daniel Simmons post goes into detail on this.
http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx
Entity Framework is similar in many ways to Linq for SQL but is not tied to MS SQL Server which Linq for SQL is. In addition EF supports more flexible mapping between your business/domain objects and the data tables. Linq for SQL supports more of a one to one mapping whereas EF supports ability to map a single object to multiple tables, or a single table to multiple objects. You do have decent designer support in both.
In the open source world, NHibernate is probably the most advanced and in many ways is the more mature product (it certainly supports a wider array of features to some regard). But with EF you get the full support of MS and the close integration into the visual studio toolset and .net framework stack. EF also as a better Linq profider than NH at the time of writing.
For a quick and dirty application i would lean towards Linq for SQL to be honest, if you can live with MS SQL Server and the mapping restrictions.
For a more complex application i would use EF or NHibernate.
You might be interested in a vote of confidence post i gave on the EF
http://blog.keithpatton.com/2008/06/24/A+Vote+Of+Confidence+For+The+Entity+Framework.aspx