There are developers working on Postgres porting out there?
I would join the team and give my support to development.
My company is really interested in this job and I could have another programmer working on it with me.
Please, let me know as soon as possible.
I am very interested in the port and have time to spare for it.
I have working knowledge of postgresql, but am pretty new to java. I have the stuff installed on debian woody, but lack the seed data. If i had access to oracle i could try to get a PLAINTEXT dump. If i knew how to unpack a jar i could look in more of the non-plain-text stuff in cvs. Without default users I havent been able to explore the client yet.
we are AT LEAST 2 people that can contribute to the project.
There's anybody else ALREADY working on Postgres porting that could give us a good starting point?
PS To extract a jar you have to execute:
jar xvf filename.jar
I have understood that port of postgress was left, the strategy change to use CMP 2 with JBOSS, this will allow to use any database.
>By: vpj-cd ( Victor Prez Jurez )
>I have understood that port of postgress was left,
>the strategy change to use CMP 2 with JBOSS,
>this will allow to use any database.
This is non clear in the forum.
If the developer team decided to abandon Postgres porting they must explain the new strategy and close this forum.
I think the idea of porting Compiere on JDBC (through JBoss, OfBiz etc.) could be a nightmare.
Imagine to use Mysql: how can you implement triggers and nested transactions using only java code?
There are too advanced Oracle features used by Compiere that are not "Sql standard" and JDBC basically implements only standard sql.
I don't want support PG in the fight PG vs. JBoss, but I know difficulties of PG port and just can imagine a total rewrite needed by a "sql standard" solution.
The Jorg's thread titled "approch" proposed a new strategy. It started a discussion but no final decision has been reported. Nor details on "how to do" and "how long it will take" have been revealed.
Anyway, if the final decision is to switch to JBoss/OFBiz I can still help the project.
You can to see this post:
>The plan is to move the current PL/SQL
>functionality to a Java middle tier. We are
>evaluating JBoss and also the option also to
>remove the requirement for a database to support
>triggers. This would make Compiere slower (and
>harder to implement/operate due to a more
>complex middle tier), but completely portable.
Ok, making Compiere completely portable is a good idea even if more complex to implement.
JBoss and OFBiz seems very powerful and helpful for us but many things have to be made to have a first "portable" release.
Do you have (or Jorg has) an idea of the amount of job and time needed to do that?
Anyway I'm still happy to help and join the developer team.
I am not actually working on the port but I would like to. Java, JDBC and PostgreSQL is no problem for me. Are you Compiere guys using a specific developpement environnement for Java?
It seems that there are more people interested in PG porting than we can expect :)
After I've installed Oracle on a PIV 1.4GhZ I think we really PG as DB, especially for small business. In fact Oracle needs a huge amount of ram and a powerful PC or, better, a server.
Postgres, instead, can be installed everywhere without critically slowing down the machine.
At this point we will really appreciate an answer from developer.
There is a developer (or a team) working on postgres porting?
My thought is that something as been made (the empty dump is part of it) but at the moment the main question is "do we still want to port compiere on postgres or do we want to implement a more standard feature as JDBC or something like that?".
I think taht due to the compiere database complexity is very hard to make it database-indipendent. For example using JDBC means using only standard sql and Oracle is very far from "standard".
So I still guess Postgres is the best choice but you, Jorg, know Compiere better than me :)
Well, to be frank, if you look at Oracle's hardware and software compatibility list which is rather short and expensive, Oracle can safely be ignored for small businesses. One apparently can run Oracle on other machines and software than specified, but since doing so invalidates any support contract one might have, there is no point in doing so. Therefore (imho) PG is the only way to go for small and small/medium businesses like, say, 5-50 people who otherwise might run Navision or some such. Anyway, doing it with PG reduces the cost of entry by at least some $6000, and more if you want more users.
IMHO it makes more sense to change to JDBC. I know that there will be a lot of work until you get a working version, but then its done. If you used JDBC you could even use MySQL or Firebird as there a drivers avaible.
I don't know anything about the source, I have not read it, but it can't be to bad ;-)
I'm not a Java developer but I would give it a try.
I think it was a good idea to give a short introduction about build system and the tools you use and the structure of compiere.
Actually Compiere is currently using JDBC. It is not the simple database access that is causing the problem. Compiere makes heavy use of functionality embedded in the Oracle database. (stored procedures, triggers etc.) These are not standard SQL. Oracle uses it's own language (PL/SQL) for embedded logic.
Postgres is in many ways "Oracle like". This is probably why it is the most likely candidate for a port.
When using a application server such as jboss the functionality that currently resides in the database might be relocated to the middle-tier eventually. This will make it possible (when using so called Container Managed PErsistence) to use Compiere with any SQL compatible database that the container (jboss) supports.
>Actually Compiere is currently using JDBC. It is not the simple database access that is causing the problem.
I see. I'm sorry for confusion I made. I try to explain better.
When I refer to JDBC and Standard Sql I mean the program uses the same sql code for all databases. Changing JDBC driver changes the database actually used, but the sql code remains the same.
About CMP one thing is not clear yet.
The sql code in Compiere remains "Oracle code"?
Is JBoss delegated to "translate" it to other RDBMS?
We have to rewrite the whole sql code in a more standard way and, after that, we can use all JBoss-supported databases?
Finally, the answer to this thread's subject seems to be: "nobody". Do I right?
PS Sorry about posting so many questions, but I'm trying to understand how I can help :)
I read somewhere about the reason why Compiere's team choose to use store procs and triggers : speed. Putting this in middleware would sure remove load from the database, but would be a lot slower. Since Compiere was designed with store procs and triggers in mind, it would require too much work to move all that logic to middle-tier (i.e. EJB). If we have to choose betweend speed and portability, I choose speed. PostgreSQL is free anyway.
I meager understanding is, it is not that they designed it using stored procs and triggers but they utilized features in these only found in Oracle thus making a port to PostgreSQL difficult.
The overall goal here is to have many people/companies use the product in hopes of getting support contracts. If a less costly cross-platform db was used (regardless of which one) then I believe the package would be used more. So, if cmp can achieve multiple db support then so be it and take the perf. hit otherwise stick with the Oracle only version.
Just my $0.02
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.