Has anyone used the EmpireDB from Apache? I am planning to use it and would like to know if there are any known issues with this new concept?
I have used ORM like Hibernate and JPA. But EmpireDB sounds like it easy.
Anyone knows its limitations then please let me know.
Thanks.
EmpireDB places impositions on your model classes; you can't just persist your designed model. You add a dependence to their codebase (which could change later). You have to write a lot more code to use it (using its Tutorial) than you would using JDO or JPA. How that is somehow "easy" i can't think.
If you need full control over the sql, you don't want to use entities for everything and hate sql/jpql strings it is the perfect tool.
It depends largely on what you plan to do with it.
Related
Is it possible to use some opensource project to help parse the sql query and convert it into the custom key-value db command (CRUD on the key). I saw the architecture of the tidb, and it seems like they have an abstracted layer. I would appreciated anyone pointing to some resources to help start the process.
I did try to research other project out there, and it seems like most of them have ad-hoc and embeded the parsing layers into their db, so I cannot really decouple and use their solutions.
You can refer to this blog:https://www.pingcap.com/blog/tidb-internal-computing/
But I don't think it is easy to decouple the code from TiDB.
You could use an SQL parser like https://github.com/pingcap/tidb/tree/master/parser but then you would have to add something that does the actual storage operations.
If you want transactions you might want to check this:
https://tikv.org/deep-dive/distributed-transaction/percolator/
I would like to create my own query language for a web api I wrote. But I have no idea where to start for it.
The language should be like SQL. For that I looked up the NHibernate code, cause I know, that they have the HQL (Hibernate Query Language) but it didn't help.
Are there any instructions or sth.? If this question is wrong here please move and/or tell me where I should ask else.
The first step is a lot of design work, starting be answering the following question:
Is this new Query Language going to be converted to SQL which will be
executed by a standard database engine, or are you going to write your
own database server as well?
If it's going to be converted to SQL (just like HQL) then map out the translations from your language to SQL on paper (and make sure you know the possible SQL constructs you may have to use). Once you've got that, you can start implementing it. Yes, this sounds like BDUF, but the language should be defined in one pass, I think, as it will be more consistent and easier to use if you do it that way. You can always implement it in a more Agile way once you've got that.
If you're going to write own database server, you're on your own....
With beta4 and latest beta5 the DB-Feature-Implementation appears to have pretty much finished. There's a couple of tutorials out there how to handle a single Database using the TableGateway Pattern, but it appears there is none for handling M-N-Relationships.
In ZF1 we had findDependantRowset() on the TableGateway which was kind of dirty, as this simply was a second Query to the databse which pretty much isn't always neccessary.
In ZF2 i expected there to be a way to have good Joins mapping to specified models, but i can't find anything within the code. Maybe i'm blind, maybe there really isn't anything like this.
Has anyone of you managed to handle joins and models all together in ZF2? If so, please be so kind to instruct me how to do it, hint me to specific points of the documentation or link me some blogpost to one who has done it.
Thanks in advance guys!
The obvious solution if you need a generic solution is to use Doctrine ORM or Propel.
If you want to use Zend\Db, then within your concrete table gateway classes, you should write a specific method that retrieves the correct rows from the linked table. This way you can ensure that the SQL is optimised for the query that you need.
I'm building a simple framework and hoping it will help me better understand OOP. Well, I've come across my first hurdle.
I'm naturally using MVC pattern and I have a user model. I then have a 'table' which manages the collection of user objects. I have an abstract model and table. Similar to Zend Framework layout.
Anyway, I'm now wondering what is the best way to execute a query? I have a database object which manages the database layer. Currently using mysqli object.
Trouble is my connection is a member of my application object, how do I access that from within my table object to execute a query? I obviously can't create a new object because that will connect to the database again. I need to reuse this same db object.
Any ideas? I understand if this isn't optimal design. Right now I'm just looking for advice.
Edit: Should I just use Doctrine?
doctrine or not?
If your intention is to learn how to write SQL Queries and to create something for your own, use mysqli or PDO.
If you would like to learn how to use a real object oriented database layer, use doctrine. With 3 pages tutorial, you can do the most general things. However some very special cases are better coded in raw sql than with doctrine. But if you know how to do things with doctrine it is a very useful library and you end up writing better, consistenter, more readabler and extensiabler (:-)) code.
you should add such dependencies in constructor.
You are able to use a static db object too, but especially for a framework like project this will get you to hell, if you try to add unit-tests or you want to refactor.
In named Patterns, you want to use dependency injection for this
So I'm having a head against the wall moment and hoping somebody can come help either remove the wall or stop my head from moving!!
Over the last 3/4 weeks I've been investigating ORM's in readyness for a new project. The ORM must map to an existing, large and ageing SQL database.
So I tried Subsonic. I really liked v2 and v3 after modding to work nicely with VB and named schemas in SQL was running OK. However, its lack of flexibility of having separate entity properties names vs column names had me pulling my hair out (sorry Rob).
I tried Entity Framework but I found like others it lacking in certain areas.
So I bit the bullet and tried nHibernate but after a week or so getting it working how I liked (with help from Codesmith to generate classes/hbms for me) I'm frustrated with the time it takes to startup (build a config object), despite trying a number of tricks to reduce this time.
I'm essentially after building a DAL class that I can share between apps and websites. Am I barking up the wrong tree? For a legacy project with 100s of tables should I go back to ado.net and use DTOs? Aarrgh!
Sorry for the ranty style of question. I don't have much hair left and I'd like to keep what I have!!
Thanks in advance, Ed
PS. I should add that I know SQL very well and not scared of getting my hands dirty to write fast queries. If anything I don't need to be hid from SQL
ORM let's you:
To map table rows to objects, that are the the workable pieces of object oriented programming.
To automatically navigate through object relationships
To easily add, edit and remove table rows
To query the database in a more intuitive way as you don't have to think of joins (this one will depend on the ORM and the query method)
To transparently handle L1 and L2 cache.
All of the above would have to be handled by hand if you werent using ORM.
PS: I agree to Dmitry as to the startup time of NHibernate (see question comments). Besides, did you try Fluent NHibernate? Fluent NHibernate is impressively easy. I couldn't believe my eyes when I first mapped a database. It's even easier than proprietary ORMs like DevExpress XPO.
The biggest benefit of an ORM tool is that it will help you layer your application correctly. Most project nowadays use a Data Layer to connect to the database. You start from the ORM tool to produce classes that correspond to your database objects. Then you define an interface using these methods. All persistence code uses the methods of this interface. This way the business logic layer is only coupled to this higher-layer interface and needs to know nothing about the database. In fact there should be no dependency on ADO.NET or even NHibernate.
Another advantage of ORM tools is that you de-couple your application from the database server. You could change the db engine and still use the same code. Also there isn't only the complexity of the SQL that the ORM hides from you. It can also help you with transactions logic and connection pooling.
I'd say that for new projects an ORM tool is a necessity. For legacy projects it isn't so much beneficial, unless of course you have the time/money to start from scratch.
In my experience, most ORMs end up being way more complex than SQL. Which defeats the entire purpose of using them.
One solution I'm enthusiastic about is LINQ2SQL. It excels as a thin layer about stored procedures or views. It's really easy to use and doesn't try to hide SQL.
There are basically two questions here:
What's great about ORMs? There are similar questions on Stackoverflow. See:
What are the advantages of using an ORM?
Is everyone here jumping on the ORM band wagon?
How can I improve NHibernate startup time? See:
http://ayende.com/Blog/archive/2007/10/26/Real-World-NHibernate-Reducing-startup-times-for-large-amount-of.aspx
http://nhforge.org/blogs/nhibernate/archive/2009/03/13/an-improvement-on-sessionfactory-initialization.aspx