Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've looked at both Liquibase and Flyway individually and on an individual comparison alone, Liquibase seems like the better tool for our needs. Some sources mention using both Liquibase and Flyway together. Liquibase seems to have everything Flyway has and more flexibility when it comes to rollbacks. The main advantage of just Flyway seems to be not having to use XML, but Liquibase allows you to specify an SQL file in their XML.
Basically, I'm still not clear on what the benefits of using Flyway & Liquibase together would be over just Liquibase, if there are any. Maybe there's a way to do it I'm not seeing as even if Liquibase was referring to valid Flyway SQL files, both tools would have to be run independently and still have the same pitfalls even though you could technically use either tool.
A small correction, before I answer question. The assumption
Liquibase seems to have everything Flyway has
isn't correct. Flyway shines when it comes to parsing SQL. You can use unmodified SQL files generated by your native tools containing all kinds of complexity like PL/SQL packages and procedures, MySQL delimiter changes, T-SQL, PostgreSQL procedures, ... With Liquibase you would have to split these in individual statements, add extra comments to the SQL files, ...
The beauty of being able to use your SQL files as-is is that you avoid lock-in. You can take your existing SQL files, start using Flyway with minimal investment and moved away later if it doesn't suit your needs anymore. Not so with Liquibase.
Also the issue of down migrations (think of them as compensating transactions, not rollbacks) is really something that sounds great in theory, but that is almost never needed in practice. See this old documentation page¹.
However when it comes down to using one or both, I certainly agree with SteveDonie (Liquibase team member) that using just one instead of the both together is almost always the better choice.
Disclaimer: I am Flyway's creator
¹ Though Flyway does support undo migrations nowadays, by reading the old documentation you'll understand the point Axel Fontaine is trying to make.
I would never recommend using both tools at the same time. In my experience, even only one of them causes conflicts/collisions from time to time in a big distributed environments(over 5 teams with access to the same DB).
I will also give you a couple of pros and cons when it comes to running these tools in projects with big, distributed teams:
FlyWay:
Cons:
Very strict when it comes to migration files changes. If someone checked in their migration file, it is not recommended to change it. It's like using force push in git in shared projects. Changing a migration(either its content or the file's name) will cause a migration failure on every machine that had the previous version of the file. The whole migration pack will need to be run from scratch. In some cases it can take a lot of time.
Pros:
Well, what was described in Cons will, at the same time, build up a level of discipline. It might be a reasonable restriction when talking about introducing simultaneous changes by several teams to a production-running application.
Liquibase:
Cons:
With a couple of tweaks should allow you to change the existing(applied) migrations. While it can be considered as a benefit, with a lot of people working on the same codebase, extra caution should be exercised. Flexibility comes at a price. It's easier to introduce some "regression" or inconsistency when such "git force push" style of changes is allowed for distributed projects.
Pros: More configurable and more flexible. Might include solutions for NoSql in the future. A couple of useful plugins(hibernate integration, for example).
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
I found around 8 Strenghts and flaws of using APEX over another program(http://en.wikipedia.org/wiki/Oracle_Application_Express), but i am not sure i quite understand WHEN to use it.
From what i understand, if you want a fast and easy-to-use development tool related to Oracle, Apex is your first choice. While if you need a complex solution, APEX won't fit.
I would like to know you guys opinion on this. In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented. We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates.
Apex is free, and an oracle XE database is free too. Apex is rapid development.
But what you're asking depends on so much more.
From what i understand, if you want a fast and easy-to-use development
tool related to Oracle, Apex is your first choice.
Is an oracle database already being used?
Easy to use dev tool: yes, sure. But as with anything, it depends on whether you have some experience with it, what the specs and expectations are, ...
While if you need a complex solution, APEX won't fit.
Well,... Would a complex solution be so much less complex in another environment? Just how complex are we thinking? In my opinion, you can go pretty far in apex and adapt it to your needs. it might involve creating templates and plugins to set up a framework, but it is doable. An example would be apex projects whom have been completely integrated with ExtJS. Apex is not the answer to everything too, but it's good. If you'd stay within the Oracle stack for more involved/complex, i'd say the next thing is ADF. Personally, i'm not convinced by that one though. It also has its pros and cons (such as: requiring java knowledge. pro for some, con for others...)
In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented.
How large is this club? How intense will the website be used?
Is there a DB already? Is it Oracle?
Who has DBA knowledge (even basic)?
Who will develop?
If your specs are up to spec, then much fiddling shouldn't be necessary after the launch.
We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates
Who will host the server? Who will run it? Who will administrate it? Do you plan to go cloud-based?
I'd almost ventured to suggest PHP may be a good alternative if this is a small project. Those developers may be easier to find and less expensive than an apex/oracle developer. But then again, if you're planning to outsource it may be less of an issue. If your oracle instance would be in the cloud somewhere, you'd even be pretty safe i'd believe...
Really, what options are you trying to compare? You're asking about apex, do you have any experience with it?
Honestly, your question is not so much a question as it is an opener to a discussion. Each technology and database will have its pro's and cons, fans and dislikers.
Personally, i really like apex. It has a lot going for it, especially when you're already invested in the Oracle stack. And it is still growing, getting good support, and great releases with lots of new features.
I can't really say how it must be set up a (reliable) service from the ground up: server and database, doesn't matter how small, you'll need some understanding and knowledge for that. If you just wing it and cross your fingers, you'll burn them somewhere down the line. Same with development. But as far as i'm concerned that goes for any other tech. Unless you outsource those aspects of course.
Etc etc. There is much and more to be discussed this way.
I put a downvote there for these reasons: there is much to be discussed, it isn't really much of a question which has a conclusive answer. And it maybe only could fetch a conclusive answer if you put more specifications up there and get people of the concurrent platforms to respond.
Edit
I'd like to react on Daniel's post.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
I'm a developer too, and i don't do server and database administration (corporate environment). Not that i haven't dabbled a bit here and there in my spare time, but i digress.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
So speaking as a PHP developer, would you even recommend PHP to achieve this? Would it be less or just as complex?
I'd also argue about complexity. I've worked on some large forms, which for me by now means there are more than your average amount of items, some dynamic actions, validations, maybe some custom process(es). I've not encountered extremely complex situations and honestly i'd question who created those expectations. Thinking outside the box may be a virtue at times, but that doesn't mean the box is always bad. Complex mechanisms or pages can maybe be broken down into more easily accomplishable parts. An example would be using modal pages to break it up.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms.
I agree about limited programming experience: you'll only create the most basic forms and reports, and having almost no experience i'd think you'd shy away from even option pages in fear of breaking something. Same thing goes for even basic db and server administration: i wouldn't like to rely on such a person when there is no experienced backup (but a very small project as is apperently being described might be acceptable).
I too am only invested in the programming side.
It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
I'd say that the templates make things very flexible and are certainly not hard to use
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Wow. I strongly disagree with this. I've maybe encountered one such thing over the course of a year and tons of forms. Not that i haven't heard of some problems on the OTN forums, but usually they had to do with upgrades.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
It is too bad that there are not that many large, public sites which use apex out there. As far as i'm aware, there are and have been large project involving apex, but those usually are in a corporate environment and thus are never shown off (can't be). I personally believe apex can be pushed a lot further than the basic forms+reports you mention (and i mean basic, because things will usually come down to forms+reports in this context).
Debugging does not have to be a pain though. If you provide enough debug messages and comments in your own code, that will help a great deal. Debugging the page, javascript console, and if needs be an autonomous error logging procedure to be used in your plsql packages,... I'd say there is plenty to help out (and if you're driven to this, you are working on some more complex material, and i assume that you have the knowledge to actually deal with the complexity you've set up).
And interesting point you raise lastly is maintenance though. I'd say a point on which apex should improve a lot is versioning, out of the box. Exports need to be improved so they can be broken up a lot easier.
Wow, look at that wall of text... I could've guessed this would turn out into a discussion.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
To start we created a few applications, just to get a feeling. Afterwards we started with the easy parts of the application. APEX is really great if you only have to build some reports and forms to edit the entries of the database. It's very fast to create these things with the integrated wizards.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms. It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
I am posting here as a guest--hopefully, I will create an account. I used O-HTML-DB from its early releases. We built pretty fine apps. I last used it in 2004, having moved to non-development roles.
Since 2007 though, I decided to revisit the tool and found out about APEX. I have since had my own test apps. I disagree with most of what the intern says.
If you have a limited objective (your business need and associated requirements), then your use of APEX will be limited. This is a very robust application, with sophisticated security features (I have been in InfoSec/Cyber since 2009.
Yes, you are correct than claims about APEX not requiring a solid development background are not accurate. You need to have a sound grasp of SQL/PL/SQL, JavaScript. But you c an also take great advantage of OTN, where developers generously share their know-how. When I started with O-HTML-DB, I had never built a DA in a business environment before. I had theoretical SQL skills. I was a Web Developer with a grasp of JavaScrip, training in Java from Learning Tree International (in addition to academics). But I and my colleague (we were two developers) learned a great deal from OTN. We built three Web apps, one of which supported over 6,000 users--just O-HTML-DB!
APEX has taken O-HTML-DB to new dimensions. You do not need to hard-code validations like we did with O-HTML-DB. Of course, you can modify, which requires a sound grasp of SQL/PL/SQL.
Maybe templating is somewhat confusing to many developers, understandably. But as you continue to "play" with APEX, I am sure you'll like it. It can do nearly anything. Only your limited vision will restrict it.
Erick
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
Our team is moving into much larger projects in size, many of which use several open source projects within them.
Any advice or best practices to keep libraries and dependancies relatively modular and easily upgradable when new releases for them are out?
To put it another way, lets say you make a program that is a fork of an open source project. As both projects grow, what is the easiest way to maintain and share updates to the core?
Advice regarding what I'm asking only please...I don't need "well you should do this instead" or "why are you"..thanks.
With clones of open source projects one of your biggest headaches will be keeping in sync/patched according to the upstream sources. You might not care about new features, but you will sure need critical bug fixes applied.
My suggestion would be to carefully wrap such inner projects into shared libraries, so you can more or less painlessly upgrade just those parts if the ABI is not broken by the changes.
One more thing - if you find and fix bugs in an open source project - don't keep the fixes to yourself. Push the patches upstream. That will make the project better and will save you days of merging with a new version.
In order of preference
Make as few changes as possible to the third party libraries. Try and get around their limitations within your code. Document your changes and then submit a patch.
If you can't get around their limitations, submit your change as a patch (this may be idealistic with the glacial pace of some projects).
If you can't do either of those things, document what you've changed in a centralized location so that the poor person doing the integration for new versions can figure out what the heck you were doing, and if the changes made are still needed.
1 and 2 are greatly preferred (however, fast and very slow respectively), while the third option will only lead to headaches and bugs as your code base deviates from the dependencies' code base. In my code, I don't even have the 3rd party code loaded up in the IDE unless I have to peruse a header file. This removes temptation to change things that aren't mine.
As far as modularity, and this is assuming you are using relatively stable 3rd party libraries, only program to the public facing interface. Just because you have the source doesn't mean you have to use it all over your code. This should allow updates to be essentially drag and drop. Now, this is completely idealistic but its what I strive for with code I work on.
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 5 years ago.
Improve this question
I'm working on a fairly big open source RTS game engine (Spring). I recently added a bunch of new C++ functions callable by Lua, and am wondering how to best document them, and at the same time also stimulate people to write/update documentation for a lot of existing Lua call-outs.
So I figured it may be nice if I could write the documentation initially as doxygen comments near the C++ functions - this is easy because the function body obviously defines exactly what the function does. However, I would like the documentation to be improved by game developers using the engine, who generally have little understanding of git (the VCS we use) or C++.
Hence, it would be ideal if there was a way to automatically generate apidocs from the C++ file, but also to have a wiki-like web interface to allow a much wider audience to update the comments, add examples, etc.
So I'm wondering, does there exist a web tool which integrates doxygen style formatting, wiki-like editing for those comments (preferably without allowing editing any other parts of the source file) and git? (to commit the comments changed through the web interface to a special branch)
We developers could then merge this branch every now and then to add the improvements to the master branch, and at the same time any improvements by developers to the documentation would end up on this web tool with just a merge of the master branch into this special branch.
I haven't found anything yet, doubt something this specific exists yet, so any suggestions are welcome!
This is a very cool idea indeed, and a couple of years ago I also had a very strong need for something like that. Unfortunately, at least back then, I wasn't able to find something like that. Doing a quick search on sourceforge and freshmeat also doesn't bring up anything related today.
But I agree that such a wiki frontend to user-contributed documentation would be very useful, I know for a fact that something like this was recently being discussed also within the Lua community (see this).
So, maybe we can determine the requirements in order to come up with a basic working draft/prototype?
Hopefully, this would get us going to initiate such a project with a minimum set of features and then simply release it into the wild as an open source project (e.g. on sourceforge), so that other users can contribute to it.
Ideally, one could use unified patches to apply changes that were contributed in such a fashion. Also, it would probably make sense to restrict modifications only to adding/editing comments, instead of allowing arbitrary modifications of text, this could probably be implemented by using a simple regex.
Maybe, one could implement something like that by modifying an existing (established) wiki software such as mediawiki. Or preferably something that's already using git as a backend for storage purposes. Then, one would mainly need to cater for those Doxygen-style comments, and provide a simple interface on top of it.
Thinking about it some more, DoxyGen itself already provides support for generating HTML documentation, so from that perspective it might actually be interesting to see, how DoxyGen could possibly be extended, so that it is well integrated with such a scripted backend that allows for easy customization of embedded source code documentation.
This would probably mainly boil down to providing a standalone script with doxygen (e.g. in python, php or perl) and then optionally embed forms in the automatically created HTML documentation, so that documentation fixes/augmentations can be sent to the corresponding script via a browser, which in turn would write any modifications back to a corresponding branch.
In the long term, it would be cool if such a script would support different types of backends (CVS, SVN or git), or at least be implemented generically enough, so that it is easily extendible.
So, if we can come up with a good design, it might even be possible that such a modification would be generally accepted as a contribution to doxygen itself, which would also give the whole thing much more exposure and momentum.
Even if the idea doesn't directly materialize into a real project, it would be interesting to see how many other users actually like the idea, so that it could possibly be mentioned in the doxygen issue tracker (https://github.com/doxygen/doxygen/issues/new).
EDIT: You may also want to check out this article titled "Documentation, Git and MediaWiki".
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 9 years ago.
Improve this question
I recently switched a project from MySQL InnoDB to PostgreSQL, and I feel bigger lags when inserting and updating data with ajax. This may be subjective. I know the Django devs recommend postgres and I know psycopg2 is supposed to be faster than MysqlDB. Personaly I like the way postgres enforces database integrity, but am mostly worried about performance for this project. Want to hear other people's opinion on this.
Why don't you measure? That's the only way to be sure about the performance. Hand waving about how slow or not is something without hard data is like trying to catch water with your hands.
Measure transactions per second or even better, requests per second with a web server stress tool like The Grinder (which can be scripted in Jython) with both MySQL backend and PostgreSQL and afterwards see if that makes a difference. If it does, ask around here, or, more specifically, ask on the pgsql-general or pgsql-performance mailing lists. There are many expert people there which know loads about it, even the main devs. There are tons of knobs on PostgreSQL configuration related to performance.
It may be incorrect usage of indexes. Simply making sure you have the right indexes, and making sure the tables are analyzed and vacuumed periodically should give rather decent results.
Even if Postgres turns out to be a minuscule slower, in some cases, my personal opinion is that the features it provides greatly outweigh the minor performance losses.
Postgres really is a beautiful database, and any time I'm using anything else, I wish I was using Postgres.
I used SQLite for the first time in the development phase of the last project. It is easy to set up, convenient to carry around from one dev system to another, etc. I have to add that when I finally moved the project to production over on MySQL, a number of subtle issues manifested themselves with MySQL that were not present at all with SQLite. Nothing big, but from now on if I have to deploy a project on MySQL, I would prefer to use MySQL in the development phase too.
SQLite. No backend server. Excellent for dev
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 6 years ago.
Improve this question
What is the best way to handle a big team that has access to a stable but no so pretty code, that is easy to introduce bugs into?
I'm looking for something along the lines of SVN locking the file(s).
Write unit tests if you don't have them already. Then start refactoring, and keep doing regression tests upon every commit.
Tell them to leave it alone.
It works, what is the benefit of changing it other than prettying it up (and the potential cost is high) so you just need to explain the cost/benefit analysis.
I would hope your developers would be smart enough to understand this and, if not, you can use your source code control system logs, rolled up tightly, to beat them to death:-) .
Svn does have a setting for locking the file to prevent concurrent access (similar to Source Safe) but I would recommend building some automated unit tests and integration tests around the fearful code. Hopefully you have a solid QA group as a safety net as well.
Write automated unit tests. If you have tests that test the code you are maintaining you can be assured that any modifications haven't broken it. Test frameworks such as JUnit can help.
Get a copy of Martin Fowler's classic book Refactoring and read it. Pay particular attention to the concept of code smells. This will point you to particular refactorings that will help with your situation.
Get a good IDE that has refactoring support built in. IDEs won't support all of the refactorings in the book but many of them will have a number of them. Eclipse and NetBeans in the Java world are free and support refactoring well.
Consider a continuous integration server like Hudson to track whether your tests are failing.
Yeah, lock it until you can write a more maintainable replacement for it.
Michael Feathers' book on legacy code will be a good read for that team. Of course, easier said than done, but that particular code can become a design debt for your software in the long run.
Black-box it in a library so it can't be messed with. Document the interface well.
Produce complete unit tests so that if it has to change, you know it still works.
If you have Subversion, locking files isn't terribly unless the code is just a few files. Subversion doesn't let you lock sub-directories, just individual files. Plus the lock can be broken.
What you probably want is a pre-commit hook script. You can do pretty much anything, but I've used it to restrict access to a certain subdirectory to specific people (branches, SQL scripts). Also, unless you have access to the server you can't break a pre-commit hook.
See the Version Control with Subversion book on Implementing Repository Hooks. The Subversion distribution should include some good examples of how to do exactly this.
I'm thinking more like refacter, if the code is hard to work with then it needs to be redone, it may take some time but it will likely be better in the long run as you won't cause as many problems.
Set up automated builds and unit tests. Any kind of repository that tracks changes is good, but won't prevent bugs.
Also, only make changes that you can run right away. The Agile methodology that says release early and often helps here. That way, you can get a better understanding of the code as you get deeper into it.
Basically, if you can, start with refactoring that doesn't change the functionality. Then introduce new functionality on top of the refactored code. Do it slowly with small, deliberate changes.
Locking the source while changes are made probably won't help as much as communicating what is changing and where. Your best approach is to make open communication channels. Set up a forum using something like Slashcode where they can discuss things openly and ask questions, and leave a record.