I invite to all developer this community work for replace all SQL code for the Query class, The reason is if we want go Standard Engine Persistence we need replace all SQL code, we know that is hard work this the reason I make a call.
So my idea is that the developer migrate a Class for day until get the goal.
This the example the work that is necessary to do:
Hmmm - it's me again with bad news for this party :-(
Note: For those who hates CAPS - sorry, this is my style to write BOLD when I can't format a textbox in my firefox.
I'm happy to see the contributors working as a team in this task.
But I must say also that this movement is totally INCONVENIENT (because of the time), maybe UNNECESSARY (because of the goal), and DETERIORATE LEGIBILITY.
I don't know now if I'm still the guardian of stable (as we don't have a PMC or even a project here) - but I must still say what I think about CODE.
INCONVENIENT!
---------------
Please - we have a clear goal - STABILIZE LIBERO!
This SO-UNSTABILIZER task is not going towards this goal. In fact is going totally against this goal.
What's this?? We already have spent 5 months stabilizing libero (that supposedly was stable 5 months ago).
Recently I asked for a FREEZE - do you think this is a freeze? This is so unstabilizer movement of code - that I doubt we're going to have a stable version in 1 year.
I encourage people instead of inventing new work - please try to keep the original goal (still very far as I see) of stabilizing.
Still we don't have:
- Sample manufacturing and payroll data in GardenWorld
- Enough documentation for testers to help
- There are still pieces not working - bad code - etc.
Maybe UNNECESSARY:
---------------------
Well - SQL has a standard, this is called SQL-ANSI. I don't see what's the benefit of migrating SQL standard to this new MQuery class.
Look at this query:
String sql = "SELECT * FROM PA_Achievement "
+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
This query run in 99.9% of RDBMS's out there - so I doubt this is helping with database independence at all.
There must be some few queries not following ANSI standard - but the movement could be to make them standard.
My guess is that database independence is hard because of some UPDATEs/DELETEs/INSERTs not following proper SQL-ANSI standard, and not following model persistence engine (although sometimes that's explicit - reason to not follow PO in some cases is because of speed).
DETERIORATE LEGIBILITY:
-------------------------
Following the same sample, please ask yourself what's more legible for oldies and for newbies:
OLD CODE:
String sql = "SELECT * FROM PA_Achievement "
+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
NEW PROPOSED CODE:
String whereClause ="PA_Measure_ID=? AND IsAchieved='Y'";
List <MAchievement> list = new Query(ctx,MAchievement.Table_Name, whereClause, null)
.setParameters(new Object[]{PA_Measure_ID}).setOrderBy("SeqNo, DateDoc").list();
I know there are A LOT of non-technical people on this project that can read java and execute simple queries on pgadmin. The first one will be clear for all of them, the second one is very hard to understand for them.
And legibility is very important asset in code, legibility means - easier maintenance, easier debug, easier for newbies to understand, etc.
I would prefer to stop this (and in fact revert the few things that were changed) and retake the FOCUS of stabilizing libero - my feeling is we're still far from stable.
Cordially,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
People participating in this task should create a branch doing this, and at the end it could be merged. Maybe.
I'd much more like a solution based on OSGI (separating services and transforming them one after another) and incorporating a real solution, not just a (partial) hack. Which surely destabilizes code.
So I absolutely agree.
Rgds,
Akos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, these are the messages from you I am used to: Well thought-out and showing a deep knowledge. ;-)
But I guess you are right. It seems to be an experiment where nobody really has an overview what would be the final result. So yes, I have the feeling it should at least move to a branch and could be merged later.
And thank you for the reminder to focus on stabilization.
-Kai
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK I too have some questions on usage and best practise with the new Query pattern.
I randomly chose an M Class that was not yet changed, and by chance picked
MProcess
Now the first method I attempted to convert was MProcess.getFromMenu()
The first question I faced was ... in the try section of the try-catch-finally section which was to be removed the results were being cached... I assumed this must be retained and the Query is not automatically caching .. but since the example had no cache I would just like to confirm?
It (caching or not) might be a useful extension to the Query though?
The second question I faced was;
There is no trxname passed to this method (as in Victor's example) so in such case do I simply pass null when calling the MQuery constructor?
Next I went to the MProcess.getProcess_ID() method.
In this method no context was passed and again the Query constructor requires one.
There is one Query constructor that does not require a context but it requires a MTable object and to instigate one of these requires a Context so I'm back to square one and that doesn't help.
Finally I came to the method MProcess.getParameters() ... there are two so the one with no parameters passed so again I faced the no context problem.
This method returns an Array of MprocessPara[].
The old code stores the selection in an attribute defined as
ArrayList<MProcessPara> list = new ArrayList<MProcessPara>();
When I created the new Query call as;
ArrayList<MProcessPara> list = (ArrayList<MProcessPara>) new Query(ctx,MProcess.Table_Name,
whereClause,null).setParameters(new Object[]
{getAD_Process_ID()}).setOrderBy("SeqNo").list();
It won't compile as the Query.list() Returns List<PO>
Put using ...
List list = new Query(ctx,MProcess.Table_Name,whereClause,null)
.setParameters(new Object[]
{getAD_Process_ID()}).setOrderBy("SeqNo").list();
m_parameters = new MProcessPara[list.size()];
list.toArray(m_parameters);
return m_parameters;
Is acceptable but is that correct?
So that was my little adventure today ... I think I probably picked a bad M class to begin with but if I get answers to these questions maybe I will have more success next time and perhaps other can learn from answers I get too?
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<IMHO except for Carlos, everyone else including me regard Carlos as the PMC Head (the pathetic opinion is mine alone (without asking for action but merely pointing to weakness to lurker behaviour), just that i forgot to include the 3 vote temporal leader vote - my omission, and i thank Carlos for adding that example to make it complete and sound thesis, but like they say in debates, if u missed it, suck it up). Thus Carlos view is still important consideration to me.>
I will abide by any advice unless there is stronger counter technical view. I offer some opinion here but i am not a strong technical person so i am not voting other than pro to the PMC here. Certainly a recommendation to a branch is ok, but just these some pointers:
1) Goal - Stabilising Libero. This is something that not many can do. It is domain specific and require experts in the Manufacturing sector. Something i cannot do. However i am ever ready to help in the Liber documentation, which i have done. So if there is more instruction from Victor on this to ask me to assist there, i m ready.
2) Time Waster. It is not so if more newbies in technical field can get involved. Perhaps we should do it in the experimental branch.
3) Legibility. This is subjective because of the goal here to move towards more PO independence. Anyway if i am the benchmark of minimal technical skill, i can read such object. However i agree with Carlos that ANSI SQL is simple English and quite layman like.
Thus i m quite split here and will go with either way. No love lost. Just that i enjoy copy/paste work alot. And i enjoy a huge ego boost each time i see my name appearing in the code submission. I knew somehow that Carlos will come and burst my bubble and end my fun.
It is a bad week for me. I lost my Dictatorship and now can't even get cheap coding work credit. I have only farming left.
red1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK - I don't want to do some unproper thing here - I think is better to revert these revisions:
- 6827 to 6833
- 6836
- 6840 to 6844
- 6846
- 6848 to 6849
- 6860 to 6866
If you agree I can make the revert - sounds not so easy - but I'll try it.
Is that ok? And then we focus again on the libero stabilization goal.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>If you agree I can make the revert - sounds not so easy - but I'll try it.
>
>Is that ok? And then we focus again on the libero stabilization goal.
I checked comited code nad it was ok.
I do not think that migration to Query class bring untsability.
I agree that it is good to postpone this task.
With new Query class code is much smaller and more easy to maintain.
All Persistent engines have helper classes which allow them to execute sql statemnts.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I'm happy to see the contributors working as a team in this task.
Is good you is happy , So you would to join to effort vs stop.
>INCONVENIENT!
>---------------
>Please - we have a clear goal - STABILIZE LIBERO!
>
>This SO-UNSTABILIZER task is not going towards this goal. In fact is going totally against this goal.
>
>What's this?? We already have spent 5 months stabilizing libero (that supposedly was stable 5 months ago).
>
>Recently I asked for a FREEZE - do you think this is a freeze? This is so unstabilizer movement of code - that I doubt we're going to have a >stable version in 1 year.
>I encourage people instead of inventing new work - please try to keep the original goal (still very far as I see) of stabilizing.
>Still we don't have:
>- Sample manufacturing and payroll data in GardenWorld
>- Enough documentation for testers to help
>- There are still pieces not working - bad code - etc.
>Maybe UNNECESSARY:
>---------------------
>Well - SQL has a standard, this is called SQL-ANSI. I don't see what's the benefit of migrating SQL standard to this new MQuery class.
>Look at this query:
>String sql = "SELECT * FROM PA_Achievement "
>+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
>This query run in 99.9% of RDBMS's out there - so I doubt this is helping with database independence at all.
>There must be some few queries not following ANSI standard - but the movement could be to make them standard.
>My guess is that database independence is hard because of some UPDATEs/DELETEs/INSERTs not following proper SQL-ANSI standard, and >not following model persistence engine (although sometimes that's explicit - reason to not follow PO in some cases is because of speed).
First class Query is not MQuery things are very different, may be for this reason you do not understand the objective this task in where many people want participate.
ANSI SQL is a standard that do not is using in this project this the reason that need a PostgreSQL convert.
The intention the use Query is implement a DAO(Data Access Object), this is know in the industry as a good Design Patterns.
So any architecture modern to have 2 important element a good Persistence Engine Framework, and DAO
But Adempiere to have not this, only a lot the SQL code distributed.
The idea the use Query class as in independence layer, that let user the Standard Persistence Object and use only objets vs SQL
Other ERPs is made this OFBiz, OpenERP, ERP5 the reason they have the right vision. So Carlos your vision is obsoleted and incorrect.
>DETERIORATE LEGIBILITY:
>-------------------------
>
>Following the same sample, please ask yourself what's more legible for oldies and for newbies:
>
>OLD CODE:
>String sql = "SELECT * FROM PA_Achievement "
>+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
>NEW PROPOSED CODE:
>String whereClause ="PA_Measure_ID=? AND IsAchieved='Y'";
>List <MAchievement> list = new Query(ctx,MAchievement.Table_Name, whereClause, null)
>.setParameters(new Object[]{PA_Measure_ID}).setOrderBy("SeqNo, DateDoc").list();
>I know there are A LOT of non-technical people on this project that can read java and execute simple queries on pgadmin. The first one will >be clear for all of them, the second one is very hard to understand for them.
>And legibility is very important asset in code, legibility means - easier maintenance, easier debug, easier for newbies to understand, etc.
This is only a pretest if you the people learnt are people that think, so any Standard Persistence use some Query language very similar to SQL, so I have not see the issue here.
But the must important and the reason now is the current Persistence Object in ADempiere is bad is slow, this do not management caches system and lazy querys, the reason is because Compiere try reinvent the wheel.
This is big problem now because the MRP is very slow for this reason and is part the my stabilization for Libero.
Kind regards
Victor Perez
www.e-evolution.com
Kind regards
Victor Perez
www.e-evolution.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Victor,
You have very good points, but they are in contradiction to Carlos'. Don't we have enough of protracted conflicts over trunk which is going on far enough?
Can we postpone decision on trunk until PMC which is entrusted to handle management of the project's roadmap and technicals.
Should we consider Trifon's words that present queries doesnt destabilizes trunk?
Or just copy this to experimental. I wouldnt like to commit twice. <-- do i sound like some fat programmer who gets pissed off when someone moves his mouse?
red1
p/s i should write a wikibook - confessions of a promiscous committer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Victor, first of all I'm really glad we got a sponsor for the libero stabilization. I'm not pessimistic, neither trying others to be. But I think we need to FOCUS. Can you share with us what are the steps needed to stabilize libero?
> Is good you is happy , So you would to join to effort vs stop.
Sorry Victor, I need to stop this - because of what was explained before. I hope there's no need to repeat.
> ANSI SQL is a standard that do not is using in this project this the reason that need a
> PostgreSQL convert.
Please let me know what is non-standard on this query:
String sql = "SELECT * FROM PA_Achievement "
+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
Saying ANSI SQL standard is not used on this project is not true - I suppose MANY of the queries are written following ANSI SQL - the convert layer maybe cover some fuzzy points of ansi-sql (like datetime support).
And if there are non-ansi SQL - it would be easier (not-so-unstabilizer) to write them properly than migrating to a new query class.
For example, Trifon said
> I checked comited code nad it was ok.
> I do not think that migration to Query class bring untsability.
I checked the commits - mostly every commit had a later fix - that's something I would call unstabilizer. The copy/paste here is not so easy - there are issues with context, transactions, parameters, etc.
> Other ERPs is made this OFBiz, OpenERP, ERP5 the reason they have the right vision. So
> Carlos your vision is obsoleted and incorrect.
I prefer not to discuss on this matter - I'm just encouraging to work toward the original goal - libero stabilization - IMHO this movement is against this goal.
I suppose you can show us how MQuery is faster than plain select with jdbc.
Just one question - so, persistence engines (like Hibernate) don't support the "SELECT * FROM PA_Achievement" written above?
> This is only a pretest if you the people learnt are people that think, so any Standard
> Persistence use some Query language very similar to SQL, so I have not see the issue
> here.
Legibility is not a pretext. Learning curve on Adempiere is so steep at this moment - to add a new layer of steepness. And I pointed also to another type of users we have.
I've seen some users that can read code and execute the SQL in pgadmin - but with the new code - they won't be empowered to do such thing.
> But the must important and the reason now is the current Persistence Object in
> ADempiere is bad is slow, this do not management caches system and lazy querys, the
> reason is because Compiere try reinvent the wheel.
PO is bad? I doubt it.
PO is slow? I doubt it.
PO doesn't manage cache? We have cache in many classes.
Simple queries are bad/slow/don't manage cache? Maybe, I'm not sure if rewritting the queries this way solve slowness and cache. I suppose the best is if you show us before rewriting and unstabilizing the whole adempiere.
> This is big problem now because the MRP is very slow for this reason and is part
> the my stabilization for Libero.
I doubt MRP is slow because of this. In all systems where I've worked, mostly performance problems are because of poorly tuned SQL.
I can help tuning SQL if you show me where is the problem (but probably you must show me also how to use libero, and if I would have sample GardenWorld data - at this moment I have very few time to try to figure how to set up modules just reading code as I did in Compiere).
> If you want to throw our work to garbage then you need also the same with Libero,
> Teo and I used this type of coding in all
I'm saying to revert the unstabilizing work at this moment to focus on the original goal. Not about reverting all the libero work.
> So if you want take your time to revert all this work vs to help you review the current.
No, I'm working towards the same original goal we agreed.
> We have 2 way for work the community can work with the current branch and you
> can work with adempiere340or more old tag I think that this have not use Query
> class
As I understand I'm still the guardian of stable. So, you can't throw me from branches/stable so easily, people also voted to keep stable with some ruling proposed by Carlos.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
* Moving to Query class doesn't improve performance. The intention is to provide a more OO API and reduce lines of code. Note that, it is also possible that using the Query class is slower if the original query only return one or two field from the table. ( yes, the initial query class is written by me ). Readability will depends a lot on the person's background. If you are Java people, you will probably prefer the Query API and like the concise syntax. On the other hand, it will be awkward to you if you are new to Java/OO but reasonably fluent with SQL.
* ADempiere is not slow because it is written in plain SQL instead of using ORM solution. I have seen system written in hibernate that's very slow too :)
* One of the primary performance issue with PO is not using PreparedStatement with the ? style. Would be great if someone can find time to fix this.
* We need to have a stable release and a plan to optimize ADempiere's performance. Just changing code from one style to another, change from one technology stack to another doesn't cut it. We need to have a plan and would need many experiment to get the right path.
* We shouldn't make such a massive movement of code in such a rush. Yes, teo and victor have previously move some code to use Query class but there are done over a period of time so people have time to review and test. The current movement is just irrational and dangerous. Also, I have say this before and I would like to stress again - we shouldn't do such a massive code changes without any code coverage ( i.e junit test case ). I mean it is just unrealistic to expect anyone to be able to review all this changes and doesn't miss any potential issue.
Regards,
Low
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Absolutely agree about the readability and performance cases.
Also about being slow not because of SQL agree as you implicitly pointed out the architecture.
> * We need to have a stable release and a plan to optimize ADempiere's
> performance. Just changing code from one style to another, change from one
> technology stack to another doesn't cut it. We need to have a plan and
> would need many experiment to get the right path.
Yes. Although I don't consider using Query changing technology stack I admit that there should be discussions about the overall _vision_ before touching the code.
> * We shouldn't make such a massive movement of code in such a rush. Yes,
> teo and victor have previously move some code to use Query class but there
> are done over a period of time so people have time to review and test. The
> current movement is just irrational and dangerous. Also, I have say this
> before and I would like to stress again - we shouldn't do such a massive
> code changes without any code coverage ( i.e junit test case ). I mean it
> is just unrealistic to expect anyone to be able to review all this changes
> and doesn't miss any potential issue.
I thought about your words and the famous formula -each 100 LOC=5 to 50 bugs- and I think you're right; doing massive changes without tests -such as junit- may give birth to hidden bugs and flaws.
However I'm also wondering shouldn't we start from something/somewhere? If things go too abstract, possibly those once interested will lose their motivation -just thinking loud.
Bahman
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>PO is bad? I doubt it.
Yes, the reason is try reinvent the wheel, I am sure that any framework that is dedicated for solve this issue is best that our current PO, Why? Because they only made Persistence and do not ERP
PO is slow? I doubt it.
yes
PO doesn't manage cache? We have cache in many classes.
Simple queries are bad/slow/don't manage cache? Maybe, I'm not sure if rewritting
the queries this way solve slowness and cache. I suppose the best is if you
show us before rewriting and unstabilizing the whole adempiere.
> This is big problem now because the MRP is very slow for this reason and is
part
> the my stabilization for Libero.
I doubt MRP is slow because of this. In all systems where I've worked, mostly
performance problems are because of poorly tuned SQL.
Yes, You can confirm only need create test class unit for Manufacturing Order or Order Distribution I only use class model object and do not use SQL, when you need generate 160 with 2000 product is very slow.
So you give the reason PO is generate poorly tuned SQL.
>As I understand I'm still the guardian of stable. So, you can't throw me from branches/stable so easily, people also voted to keep stable with >some ruling proposed by Carlos.
Carlos I ask you why do you not stop this improve when Teo and me made commit with Query Class in Libero and other class core if you are the guardian of stable, Now that we using this API the way intensive you do not agree.
Please somebody can say where out PO engine implement a cache as this
If you want to throw our work to garbage then you need also the same with Libero, Teo and I used this type of coding in all
place and even was changed some core classes without problem. MStorege , MLocator , MWarehouse, MInOut, etc you can open the Query class and the Eclipse and find all references this class.
So if you want take your time to revert all this work vs to help you review the current.
We have 2 way for work the community can work with the current branch and you can work with adempiere340or more old tag I think that this have not use Query class
Kind regards
Victor Perez
www.e-evolution.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that now there are some issues regarding ADempiere's future direction and maybe the best thing is if everyone who is directly involved in this project (contributing, implementing, testing, consulting etc) can give us a feedback: WHAT EXACTLY DO YOU EXPECT FROM ADEMPIERE PROJECT AND HOW CAN WE HELP EACH OTHER ?
Anyway, we need to establish a direction or a roadmap, because EVEN if we are Open Source Project, we are companies that need to make money from this project, so i guess we share same interest.
I will start first; I expect following things:
1. Stability - i need this because i need to make money from consulting & implementation services
2. mature & well tested specialized technology (e.g. Hibernate for persistence engine) - i need this because specialized systems are much better, mature technology, tested by a different community and evolve separately.
3. Integration with BI solutions like Pentaho BI or Oracle BI.
--
Regarding using the new Query API, you know that i always like this idea because it brings us near a robust persistence engine like (hibernate, Oracle TopLink etc) we will give us HUGE benefits (don't need to enumerate here).
How to do this ?
Maybe creating a new branch to this changes and then merge back to trunk after stable release is the best option. But anyway, leaving all feelings back, i think that we all agree that we need to derogate the persistence to a much more qualified project is a smart move. The timing is the issue. Isn't it?
To conclude, i am very eager to find you who do you see things ? What do you expect from ADempiere and how can you help ?
--
Best regards,
Teo Sarca - www.arhipac.ro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm catching on to Teo's request for feedback of what I expect from Adempiere in the near future.
* It must be stable. I'm running my business and other's businesses on it and it must not stop working at any time.
* When I upgraded to the 3.52a release the invoices stopped printing due to a bug. To get the invoice printing to work Adempiere must be patched. This shouldn't happen in releases.
* User friendly - If the system isn't user friendly it's harder to convince people to work in it.
* Secure - I posted previously a message about Adempiere being easy to break into and that it can't be on an untrusted network. It's OK to have an insecure application as long as everybody knows it's insecure. For business critical data the implementors must know how to secure Adempiere.
I'm working on the user friendliness part (the Account Editor was the first step) and when I have time I'd like to work on the security part.
One example on how user friendliness can be improved is to increase the searchability in accounts (you can't zoom to documents from accounts-view today) and make a really simple form for creating manual general ledger entries. Manual general ledger entries today are far too much work than what a normal accountant is used to in other systems.
Perhaps this discussion should continue on a different post from now on?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree with Teo, doing such a wide change in a soon to be released(?) project, without a vote and, most important, without a clear roadmap toward Adempiere Nextgen is dangerous and maybe a waste of time and energy.
I'm not blaming no one, as a developer I'm the first who hate to do things and then trash them because of flawed design or lack of vision
My wish list for next Christmas is the following:
* Stabilization: I just work on stable release right now because I'm working on localization
* Extensibility: Owing to the before mentioned localization project I'm facing a lot of problems trying not to touch the project and just using modelvalidator:
** The accounting engine should be more flexible, using interfaces and specifing which accounting class to use at base document level and derived document level with fallback to standard behaviour.
** Subdocument type sould be extended to every base type, not only for orders, and bound to a table, not a ref list, so you can add subtypes dynamically and distinguish for instance different invoice type without creating new basedoctype.
** DocTax[] should be memebers of Doc class, today in factsValidate or docvalidate methods you don't have access to the whole document because doctax lines are not part of Doc class but a private member of some Doc_xxx classes without a getter. Also the DocTax class is final so you cannot extend it without touching the standard project.
** Get rid of hardcoded behaviours, like the information line displayed on StatusBar using GridTab.getTrxInfo() (we could specify a method to invoke at tab level and again a fallback to current method.
* Stay current: I mean we are in the verge of modifing the whole project for something that maybe has not surplus value, while for many years we lack to update basic components like jdbc drivers, jboss or jasper (I know we are doing it right now)
* Release often: I don't know when we are going to release the next version (360? 400?) because there is such new stuff, maybe we should have split it on subprojects and release new stable version when single projects are finalized, because the real test begin with release.
* Make the most of people: we saw that many people are willing to contribute on repetitive coding tasks, we should capitalize on that and point them to whatever the community agree on building a better Adempiere.
Just my two cents
Angelo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From Carlos post i got minor question to Victor too:
How do i see SQL full stmt that i can copy and test in TOAD or DB Editor?
If i put stop or break.. i m not sure where to get the full SQL value? I think that needs to be documented better before we proceed.
But to Carlos, i think u have to consider others point of view. Cant we leave just these few queries in? They are not many. You should have drop a word on this 2 days earlier and save me the learning curve. But anyway i learnt well from Trifon.
I hope this is frozen and i continue after the next release. Meanwhile i will help Victor to document the JPA impact for oldies and debug guide. I think that is also important Victor.
red1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> But to Carlos, i think u have to consider others point of view. Cant we leave just these
> few queries in? They are not many.
I asked before reverting precisely for this. I don't want to be aggressive or do something improper. I haven't reverted anything - and I'll try not to do it if there are good reasons to not do it.
> You should have drop a word on this 2 days earlier and save me the learning curve.
2 days before I didn't saw the magnitude of the changes, just after I started seeing a commit - a fix for previous commit, then a new commit, then a fix for the previous commit. I became alarmed. Sorry for not catching the impact before.
Victor,
> Carlos I ask you why do you not stop this improve when Teo and me made commit
> with Query Class in Libero and other class core if you are the guardian of
> stable, Now that we using this API the way intensive you do not agree.
Same answer as before - changing one class is a thing - changing the whole adempiere is another. This is going against libero stabilization - the changes you and Teo did were within the libero stabilization goal.
But anyways - I even said something privately to Teo that can shock many people here - but I'll dare to throw it here:
- 310 to 320 the goal was stabilization - so we fixed more than 300 bugs from compiere days.
- 320 to 340 the goal was extensibility - so we changed a lot the core and added lot of extensibility options - but we didn't advance functionally
- 340 to 400 the goal is new functionality - this represents a big jump functionally speaking (manufacturing - payroll - fixed assets - gosh we're brave!).
What I said to Teo is that 340 to 400 would be a lot easier if we have frozen core - this is - just focus on stabilization of new functionalities - and leave the core still.
That would make the stabilization work easier. Now we have added lots of unstabilizing things - and we keep adding them (that's why I called to set a freeze date).
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Developer!
I invite to all developer this community work for replace all SQL code for the Query class, The reason is if we want go Standard Engine Persistence we need replace all SQL code, we know that is hard work this the reason I make a call.
So my idea is that the developer migrate a Class for day until get the goal.
This the example the work that is necessary to do:
http://adempiere.svn.sourceforge.net/viewvc/adempiere/branches/stable/base/src/org/compiere/model/MCash.java?r1=6827&r2=6826&pathrev=6827
MCash retValue = null;
// Existing Journal
String sql;
sql = "SELECT * FROM C_Cash c "
+ "WHERE c.AD_Org_ID=?" // #1
+ " AND TRUNC(c.StatementDate)=?" // #2
+ " AND c.Processed='N'"
+ " AND EXISTS (SELECT * FROM C_CashBook cb "
+ "WHERE c.C_CashBook_ID=cb.C_CashBook_ID AND cb.AD_Org_ID=c.AD_Org_ID"
+ " AND cb.C_Currency_ID=?)"; // #3
PreparedStatement pstmt = null;
ResultSet rs = null;
try
{
pstmt = DB.prepareStatement (sql, trxName);
pstmt.setInt (1, AD_Org_ID);
pstmt.setTimestamp (2, TimeUtil.getDay(dateAcct));
pstmt.setInt (3, C_Currency_ID);
rs = pstmt.executeQuery ();
if (rs.next ())
retValue = new MCash (ctx, rs, trxName);
}
catch (Exception e)
{
s_log.log(Level.SEVERE, sql, e);
}
finally
{
DB.close(rs, pstmt);
rs = null; pstmt = null;
}
Replace for
String whereClause = "c.AD_Org_ID=?" // #1
+ " AND TRUNC(c.StatementDate)=?" // #2
+ " AND c.Processed='N'"
+ " AND EXISTS (SELECT * FROM C_CashBook cb "
+ "WHERE c.C_CashBook_ID=cb.C_CashBook_ID AND cb.AD_Org_ID=c.AD_Org_ID"
+ " AND cb.C_Currency_ID=?)"; // #3
MCash retValue = (MCash)new Query(ctx,MCash.Table_Name,whereClause,trxName)
.setParameters(new Object[]{AD_Org_ID,TimeUtil.getDay(dateAcct),C_Currency_ID}).first();
Is very important validate the code for do not introducing new bug in code that now is stable.
What do you think?
kind regards
Victor Perez
www.e-evolution.com
Hi Victor,
I welcome your initiative and i join the effort.
One class per day per Adempiere developer and joinly we will be able to migrate to Query class and to better Adempeire!
Kind regards,
Trifon
Hi Developers
I created a request feature for register the migrated model class and the test that was
executed for validate that all is fine
http://sourceforge.net/tracker/index.php?func=detail&aid=2214883&group_id=176962&atid=879335
Kind regards
Victor Perez
www.e-evolution.com
Hmmm - it's me again with bad news for this party :-(
Note: For those who hates CAPS - sorry, this is my style to write BOLD when I can't format a textbox in my firefox.
I'm happy to see the contributors working as a team in this task.
But I must say also that this movement is totally INCONVENIENT (because of the time), maybe UNNECESSARY (because of the goal), and DETERIORATE LEGIBILITY.
I don't know now if I'm still the guardian of stable (as we don't have a PMC or even a project here) - but I must still say what I think about CODE.
INCONVENIENT!
---------------
Please - we have a clear goal - STABILIZE LIBERO!
This SO-UNSTABILIZER task is not going towards this goal. In fact is going totally against this goal.
What's this?? We already have spent 5 months stabilizing libero (that supposedly was stable 5 months ago).
Recently I asked for a FREEZE - do you think this is a freeze? This is so unstabilizer movement of code - that I doubt we're going to have a stable version in 1 year.
I encourage people instead of inventing new work - please try to keep the original goal (still very far as I see) of stabilizing.
Still we don't have:
- Sample manufacturing and payroll data in GardenWorld
- Enough documentation for testers to help
- There are still pieces not working - bad code - etc.
Maybe UNNECESSARY:
---------------------
Well - SQL has a standard, this is called SQL-ANSI. I don't see what's the benefit of migrating SQL standard to this new MQuery class.
Look at this query:
String sql = "SELECT * FROM PA_Achievement "
+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
This query run in 99.9% of RDBMS's out there - so I doubt this is helping with database independence at all.
There must be some few queries not following ANSI standard - but the movement could be to make them standard.
My guess is that database independence is hard because of some UPDATEs/DELETEs/INSERTs not following proper SQL-ANSI standard, and not following model persistence engine (although sometimes that's explicit - reason to not follow PO in some cases is because of speed).
DETERIORATE LEGIBILITY:
-------------------------
Following the same sample, please ask yourself what's more legible for oldies and for newbies:
OLD CODE:
String sql = "SELECT * FROM PA_Achievement "
+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
NEW PROPOSED CODE:
String whereClause ="PA_Measure_ID=? AND IsAchieved='Y'";
List <MAchievement> list = new Query(ctx,MAchievement.Table_Name, whereClause, null)
.setParameters(new Object[]{PA_Measure_ID}).setOrderBy("SeqNo, DateDoc").list();
I know there are A LOT of non-technical people on this project that can read java and execute simple queries on pgadmin. The first one will be clear for all of them, the second one is very hard to understand for them.
And legibility is very important asset in code, legibility means - easier maintenance, easier debug, easier for newbies to understand, etc.
I would prefer to stop this (and in fact revert the few things that were changed) and retake the FOCUS of stabilizing libero - my feeling is we're still far from stable.
Cordially,
Carlos Ruiz
+1000 from me, absolutely agree
People participating in this task should create a branch doing this, and at the end it could be merged. Maybe.
I'd much more like a solution based on OSGI (separating services and transforming them one after another) and incorporating a real solution, not just a (partial) hack. Which surely destabilizes code.
So I absolutely agree.
Rgds,
Akos
Hi Carlos,
yes, these are the messages from you I am used to: Well thought-out and showing a deep knowledge. ;-)
But I guess you are right. It seems to be an experiment where nobody really has an overview what would be the final result. So yes, I have the feeling it should at least move to a branch and could be merged later.
And thank you for the reminder to focus on stabilization.
-Kai
I joined in this effort but i am not an expert. So i did it slowly with Trifon and Victor's help. So far so good.
Thus newbies are most welcome, and we can guide you with simple java to do.
Please reply here if can.
red1
I got one question. How to apply this to Static Classes? In static classes i cannot introduce the non static method get*_ID() inside the Query call.
OK I too have some questions on usage and best practise with the new Query pattern.
I randomly chose an M Class that was not yet changed, and by chance picked
MProcess
Now the first method I attempted to convert was MProcess.getFromMenu()
The first question I faced was ... in the try section of the try-catch-finally section which was to be removed the results were being cached... I assumed this must be retained and the Query is not automatically caching .. but since the example had no cache I would just like to confirm?
It (caching or not) might be a useful extension to the Query though?
The second question I faced was;
There is no trxname passed to this method (as in Victor's example) so in such case do I simply pass null when calling the MQuery constructor?
Next I went to the MProcess.getProcess_ID() method.
In this method no context was passed and again the Query constructor requires one.
There is one Query constructor that does not require a context but it requires a MTable object and to instigate one of these requires a Context so I'm back to square one and that doesn't help.
Finally I came to the method MProcess.getParameters() ... there are two so the one with no parameters passed so again I faced the no context problem.
This method returns an Array of MprocessPara[].
The old code stores the selection in an attribute defined as
ArrayList<MProcessPara> list = new ArrayList<MProcessPara>();
When I created the new Query call as;
ArrayList<MProcessPara> list = (ArrayList<MProcessPara>) new Query(ctx,MProcess.Table_Name,
whereClause,null).setParameters(new Object[]
{getAD_Process_ID()}).setOrderBy("SeqNo").list();
It won't compile as the Query.list() Returns List<PO>
Put using ...
List list = new Query(ctx,MProcess.Table_Name,whereClause,null)
.setParameters(new Object[]
{getAD_Process_ID()}).setOrderBy("SeqNo").list();
m_parameters = new MProcessPara[list.size()];
list.toArray(m_parameters);
return m_parameters;
Is acceptable but is that correct?
So that was my little adventure today ... I think I probably picked a bad M class to begin with but if I get answers to these questions maybe I will have more success next time and perhaps other can learn from answers I get too?
colin
<IMHO except for Carlos, everyone else including me regard Carlos as the PMC Head (the pathetic opinion is mine alone (without asking for action but merely pointing to weakness to lurker behaviour), just that i forgot to include the 3 vote temporal leader vote - my omission, and i thank Carlos for adding that example to make it complete and sound thesis, but like they say in debates, if u missed it, suck it up). Thus Carlos view is still important consideration to me.>
I will abide by any advice unless there is stronger counter technical view. I offer some opinion here but i am not a strong technical person so i am not voting other than pro to the PMC here. Certainly a recommendation to a branch is ok, but just these some pointers:
1) Goal - Stabilising Libero. This is something that not many can do. It is domain specific and require experts in the Manufacturing sector. Something i cannot do. However i am ever ready to help in the Liber documentation, which i have done. So if there is more instruction from Victor on this to ask me to assist there, i m ready.
2) Time Waster. It is not so if more newbies in technical field can get involved. Perhaps we should do it in the experimental branch.
3) Legibility. This is subjective because of the goal here to move towards more PO independence. Anyway if i am the benchmark of minimal technical skill, i can read such object. However i agree with Carlos that ANSI SQL is simple English and quite layman like.
Thus i m quite split here and will go with either way. No love lost. Just that i enjoy copy/paste work alot. And i enjoy a huge ego boost each time i see my name appearing in the code submission. I knew somehow that Carlos will come and burst my bubble and end my fun.
It is a bad week for me. I lost my Dictatorship and now can't even get cheap coding work credit. I have only farming left.
red1
OK - I don't want to do some unproper thing here - I think is better to revert these revisions:
- 6827 to 6833
- 6836
- 6840 to 6844
- 6846
- 6848 to 6849
- 6860 to 6866
If you agree I can make the revert - sounds not so easy - but I'll try it.
Is that ok? And then we focus again on the libero stabilization goal.
Regards,
Carlos Ruiz
Hi Carlos,
>If you agree I can make the revert - sounds not so easy - but I'll try it.
>
>Is that ok? And then we focus again on the libero stabilization goal.
I checked comited code nad it was ok.
I do not think that migration to Query class bring untsability.
I agree that it is good to postpone this task.
With new Query class code is much smaller and more easy to maintain.
All Persistent engines have helper classes which allow them to execute sql statemnts.
Kind regards,
Trifon
Hi Carlos!
>I'm happy to see the contributors working as a team in this task.
Is good you is happy , So you would to join to effort vs stop.
>INCONVENIENT!
>---------------
>Please - we have a clear goal - STABILIZE LIBERO!
>
>This SO-UNSTABILIZER task is not going towards this goal. In fact is going totally against this goal.
>
>What's this?? We already have spent 5 months stabilizing libero (that supposedly was stable 5 months ago).
>
>Recently I asked for a FREEZE - do you think this is a freeze? This is so unstabilizer movement of code - that I doubt we're going to have a >stable version in 1 year.
>I encourage people instead of inventing new work - please try to keep the original goal (still very far as I see) of stabilizing.
>Still we don't have:
>- Sample manufacturing and payroll data in GardenWorld
>- Enough documentation for testers to help
>- There are still pieces not working - bad code - etc.
Fortunately not all are pessimistic as you, Yesterday I receipt the answer of a sponsored that set money for finish this work.
http://www.adempiere.com/wiki/index.php/Sponsored_Development:_Libero_ADempiere_Manufacturing_Stabilization
>Maybe UNNECESSARY:
>---------------------
>Well - SQL has a standard, this is called SQL-ANSI. I don't see what's the benefit of migrating SQL standard to this new MQuery class.
>Look at this query:
>String sql = "SELECT * FROM PA_Achievement "
>+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
>This query run in 99.9% of RDBMS's out there - so I doubt this is helping with database independence at all.
>There must be some few queries not following ANSI standard - but the movement could be to make them standard.
>My guess is that database independence is hard because of some UPDATEs/DELETEs/INSERTs not following proper SQL-ANSI standard, and >not following model persistence engine (although sometimes that's explicit - reason to not follow PO in some cases is because of speed).
First class Query is not MQuery things are very different, may be for this reason you do not understand the objective this task in where many people want participate.
ANSI SQL is a standard that do not is using in this project this the reason that need a PostgreSQL convert.
The intention the use Query is implement a DAO(Data Access Object), this is know in the industry as a good Design Patterns.
http://www.ibm.com/developerworks/library/j-dao/
http://java.sun.com/blueprints/patterns/DAO.html
So any architecture modern to have 2 important element a good Persistence Engine Framework, and DAO
But Adempiere to have not this, only a lot the SQL code distributed.
The idea the use Query class as in independence layer, that let user the Standard Persistence Object and use only objets vs SQL
Other ERPs is made this OFBiz, OpenERP, ERP5 the reason they have the right vision. So Carlos your vision is obsoleted and incorrect.
>DETERIORATE LEGIBILITY:
>-------------------------
>
>Following the same sample, please ask yourself what's more legible for oldies and for newbies:
>
>OLD CODE:
>String sql = "SELECT * FROM PA_Achievement "
>+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
>NEW PROPOSED CODE:
>String whereClause ="PA_Measure_ID=? AND IsAchieved='Y'";
>List <MAchievement> list = new Query(ctx,MAchievement.Table_Name, whereClause, null)
>.setParameters(new Object[]{PA_Measure_ID}).setOrderBy("SeqNo, DateDoc").list();
>I know there are A LOT of non-technical people on this project that can read java and execute simple queries on pgadmin. The first one will >be clear for all of them, the second one is very hard to understand for them.
>And legibility is very important asset in code, legibility means - easier maintenance, easier debug, easier for newbies to understand, etc.
This is only a pretest if you the people learnt are people that think, so any Standard Persistence use some Query language very similar to SQL, so I have not see the issue here.
http://www.datanucleus.org/products/accessplatform_1_0/jpa/jpql.html
http://www.datanucleus.org/products/accessplatform_1_0/jpa/query.html
But the must important and the reason now is the current Persistence Object in ADempiere is bad is slow, this do not management caches system and lazy querys, the reason is because Compiere try reinvent the wheel.
This is big problem now because the MRP is very slow for this reason and is part the my stabilization for Libero.
Kind regards
Victor Perez
www.e-evolution.com
Kind regards
Victor Perez
www.e-evolution.com
Victor,
You have very good points, but they are in contradiction to Carlos'. Don't we have enough of protracted conflicts over trunk which is going on far enough?
Can we postpone decision on trunk until PMC which is entrusted to handle management of the project's roadmap and technicals.
Should we consider Trifon's words that present queries doesnt destabilizes trunk?
Or just copy this to experimental. I wouldnt like to commit twice. <-- do i sound like some fat programmer who gets pissed off when someone moves his mouse?
red1
p/s i should write a wikibook - confessions of a promiscous committer.
Victor, first of all I'm really glad we got a sponsor for the libero stabilization. I'm not pessimistic, neither trying others to be. But I think we need to FOCUS. Can you share with us what are the steps needed to stabilize libero?
> Is good you is happy , So you would to join to effort vs stop.
Sorry Victor, I need to stop this - because of what was explained before. I hope there's no need to repeat.
> ANSI SQL is a standard that do not is using in this project this the reason that need a
> PostgreSQL convert.
Please let me know what is non-standard on this query:
String sql = "SELECT * FROM PA_Achievement "
+ "WHERE PA_Measure_ID=? AND IsAchieved='Y' ORDER BY SeqNo, DateDoc";
Saying ANSI SQL standard is not used on this project is not true - I suppose MANY of the queries are written following ANSI SQL - the convert layer maybe cover some fuzzy points of ansi-sql (like datetime support).
And if there are non-ansi SQL - it would be easier (not-so-unstabilizer) to write them properly than migrating to a new query class.
For example, Trifon said
> I checked comited code nad it was ok.
> I do not think that migration to Query class bring untsability.
I checked the commits - mostly every commit had a later fix - that's something I would call unstabilizer. The copy/paste here is not so easy - there are issues with context, transactions, parameters, etc.
> Other ERPs is made this OFBiz, OpenERP, ERP5 the reason they have the right vision. So
> Carlos your vision is obsoleted and incorrect.
I prefer not to discuss on this matter - I'm just encouraging to work toward the original goal - libero stabilization - IMHO this movement is against this goal.
I suppose you can show us how MQuery is faster than plain select with jdbc.
Just one question - so, persistence engines (like Hibernate) don't support the "SELECT * FROM PA_Achievement" written above?
> This is only a pretest if you the people learnt are people that think, so any Standard
> Persistence use some Query language very similar to SQL, so I have not see the issue
> here.
Legibility is not a pretext. Learning curve on Adempiere is so steep at this moment - to add a new layer of steepness. And I pointed also to another type of users we have.
I've seen some users that can read code and execute the SQL in pgadmin - but with the new code - they won't be empowered to do such thing.
> But the must important and the reason now is the current Persistence Object in
> ADempiere is bad is slow, this do not management caches system and lazy querys, the
> reason is because Compiere try reinvent the wheel.
PO is bad? I doubt it.
PO is slow? I doubt it.
PO doesn't manage cache? We have cache in many classes.
Simple queries are bad/slow/don't manage cache? Maybe, I'm not sure if rewritting the queries this way solve slowness and cache. I suppose the best is if you show us before rewriting and unstabilizing the whole adempiere.
> This is big problem now because the MRP is very slow for this reason and is part
> the my stabilization for Libero.
I doubt MRP is slow because of this. In all systems where I've worked, mostly performance problems are because of poorly tuned SQL.
I can help tuning SQL if you show me where is the problem (but probably you must show me also how to use libero, and if I would have sample GardenWorld data - at this moment I have very few time to try to figure how to set up modules just reading code as I did in Compiere).
> If you want to throw our work to garbage then you need also the same with Libero,
> Teo and I used this type of coding in all
I'm saying to revert the unstabilizing work at this moment to focus on the original goal. Not about reverting all the libero work.
> So if you want take your time to revert all this work vs to help you review the current.
No, I'm working towards the same original goal we agreed.
> We have 2 way for work the community can work with the current branch and you
> can work with adempiere340or more old tag I think that this have not use Query
> class
As I understand I'm still the guardian of stable. So, you can't throw me from branches/stable so easily, people also voted to keep stable with some ruling proposed by Carlos.
Regards,
Carlos Ruiz
Hi all,
Let me join the funs too :)
* Moving to Query class doesn't improve performance. The intention is to provide a more OO API and reduce lines of code. Note that, it is also possible that using the Query class is slower if the original query only return one or two field from the table. ( yes, the initial query class is written by me ). Readability will depends a lot on the person's background. If you are Java people, you will probably prefer the Query API and like the concise syntax. On the other hand, it will be awkward to you if you are new to Java/OO but reasonably fluent with SQL.
* ADempiere is not slow because it is written in plain SQL instead of using ORM solution. I have seen system written in hibernate that's very slow too :)
* One of the primary performance issue with PO is not using PreparedStatement with the ? style. Would be great if someone can find time to fix this.
* We need to have a stable release and a plan to optimize ADempiere's performance. Just changing code from one style to another, change from one technology stack to another doesn't cut it. We need to have a plan and would need many experiment to get the right path.
* We shouldn't make such a massive movement of code in such a rush. Yes, teo and victor have previously move some code to use Query class but there are done over a period of time so people have time to review and test. The current movement is just irrational and dangerous. Also, I have say this before and I would like to stress again - we shouldn't do such a massive code changes without any code coverage ( i.e junit test case ). I mean it is just unrealistic to expect anyone to be able to review all this changes and doesn't miss any potential issue.
Regards,
Low
Its more fun if you said it earlier! Or is it? :->
Anyway about JUnit testing, someone by the name Ivanceras said he has done it quite easily and powerfully. He promised to send us.. so we wait.
But meanwhile who else can help on such testing codework. I dont mind swtiching to learning that meanwhile waiting for the freeze to blow over. :-)
red1
Absolutely agree about the readability and performance cases.
Also about being slow not because of SQL agree as you implicitly pointed out the architecture.
> * We need to have a stable release and a plan to optimize ADempiere's
> performance. Just changing code from one style to another, change from one
> technology stack to another doesn't cut it. We need to have a plan and
> would need many experiment to get the right path.
Yes. Although I don't consider using Query changing technology stack I admit that there should be discussions about the overall _vision_ before touching the code.
> * We shouldn't make such a massive movement of code in such a rush. Yes,
> teo and victor have previously move some code to use Query class but there
> are done over a period of time so people have time to review and test. The
> current movement is just irrational and dangerous. Also, I have say this
> before and I would like to stress again - we shouldn't do such a massive
> code changes without any code coverage ( i.e junit test case ). I mean it
> is just unrealistic to expect anyone to be able to review all this changes
> and doesn't miss any potential issue.
I thought about your words and the famous formula -each 100 LOC=5 to 50 bugs- and I think you're right; doing massive changes without tests -such as junit- may give birth to hidden bugs and flaws.
However I'm also wondering shouldn't we start from something/somewhere? If things go too abstract, possibly those once interested will lose their motivation -just thinking loud.
Bahman
>PO is bad? I doubt it.
Yes, the reason is try reinvent the wheel, I am sure that any framework that is dedicated for solve this issue is best that our current PO, Why? Because they only made Persistence and do not ERP
PO is slow? I doubt it.
yes
PO doesn't manage cache? We have cache in many classes.
Simple queries are bad/slow/don't manage cache? Maybe, I'm not sure if rewritting
the queries this way solve slowness and cache. I suppose the best is if you
show us before rewriting and unstabilizing the whole adempiere.
> This is big problem now because the MRP is very slow for this reason and is
part
> the my stabilization for Libero.
I doubt MRP is slow because of this. In all systems where I've worked, mostly
performance problems are because of poorly tuned SQL.
Yes, You can confirm only need create test class unit for Manufacturing Order or Order Distribution I only use class model object and do not use SQL, when you need generate 160 with 2000 product is very slow.
So you give the reason PO is generate poorly tuned SQL.
>As I understand I'm still the guardian of stable. So, you can't throw me from branches/stable so easily, people also voted to keep stable with >some ruling proposed by Carlos.
Carlos I ask you why do you not stop this improve when Teo and me made commit with Query Class in Libero and other class core if you are the guardian of stable, Now that we using this API the way intensive you do not agree.
Please somebody can say where out PO engine implement a cache as this
http://edocs.bea.com/kodo/docs41/full/html/ref_guide_caching.html#ref_guide_cache
http://www.oracle.com/technology/products/ias/toplink/JPA/essentials/toplink-jpa-extensions.html#TopLinkCaching
Where we implementing some this in current PO engine?
http://wiki.eclipse.org/Introduction_to_Mappings_%28ELUG%29#Indirection_.28Lazy_Loading.29
http://www.hibernate.org/162.html
Kind regards
Victor Perez
www.e-evolution.com
Hi Carlos,
If you want to throw our work to garbage then you need also the same with Libero, Teo and I used this type of coding in all
place and even was changed some core classes without problem. MStorege , MLocator , MWarehouse, MInOut, etc you can open the Query class and the Eclipse and find all references this class.
So if you want take your time to revert all this work vs to help you review the current.
We have 2 way for work the community can work with the current branch and you can work with adempiere340or more old tag I think that this have not use Query class
Kind regards
Victor Perez
www.e-evolution.com
Hi all,
Yet Another Flame :(
I understand that now there are some issues regarding ADempiere's future direction and maybe the best thing is if everyone who is directly involved in this project (contributing, implementing, testing, consulting etc) can give us a feedback: WHAT EXACTLY DO YOU EXPECT FROM ADEMPIERE PROJECT AND HOW CAN WE HELP EACH OTHER ?
Anyway, we need to establish a direction or a roadmap, because EVEN if we are Open Source Project, we are companies that need to make money from this project, so i guess we share same interest.
I will start first; I expect following things:
1. Stability - i need this because i need to make money from consulting & implementation services
2. mature & well tested specialized technology (e.g. Hibernate for persistence engine) - i need this because specialized systems are much better, mature technology, tested by a different community and evolve separately.
3. Integration with BI solutions like Pentaho BI or Oracle BI.
--
Regarding using the new Query API, you know that i always like this idea because it brings us near a robust persistence engine like (hibernate, Oracle TopLink etc) we will give us HUGE benefits (don't need to enumerate here).
How to do this ?
Maybe creating a new branch to this changes and then merge back to trunk after stable release is the best option. But anyway, leaving all feelings back, i think that we all agree that we need to derogate the persistence to a much more qualified project is a smart move. The timing is the issue. Isn't it?
To conclude, i am very eager to find you who do you see things ? What do you expect from ADempiere and how can you help ?
--
Best regards,
Teo Sarca - www.arhipac.ro
I'm catching on to Teo's request for feedback of what I expect from Adempiere in the near future.
* It must be stable. I'm running my business and other's businesses on it and it must not stop working at any time.
* When I upgraded to the 3.52a release the invoices stopped printing due to a bug. To get the invoice printing to work Adempiere must be patched. This shouldn't happen in releases.
* User friendly - If the system isn't user friendly it's harder to convince people to work in it.
* Secure - I posted previously a message about Adempiere being easy to break into and that it can't be on an untrusted network. It's OK to have an insecure application as long as everybody knows it's insecure. For business critical data the implementors must know how to secure Adempiere.
I'm working on the user friendliness part (the Account Editor was the first step) and when I have time I'd like to work on the security part.
One example on how user friendliness can be improved is to increase the searchability in accounts (you can't zoom to documents from accounts-view today) and make a really simple form for creating manual general ledger entries. Manual general ledger entries today are far too much work than what a normal accountant is used to in other systems.
Perhaps this discussion should continue on a different post from now on?
Hi all,
I totally agree with Teo, doing such a wide change in a soon to be released(?) project, without a vote and, most important, without a clear roadmap toward Adempiere Nextgen is dangerous and maybe a waste of time and energy.
I'm not blaming no one, as a developer I'm the first who hate to do things and then trash them because of flawed design or lack of vision
My wish list for next Christmas is the following:
* Stabilization: I just work on stable release right now because I'm working on localization
* Extensibility: Owing to the before mentioned localization project I'm facing a lot of problems trying not to touch the project and just using modelvalidator:
** The accounting engine should be more flexible, using interfaces and specifing which accounting class to use at base document level and derived document level with fallback to standard behaviour.
** Subdocument type sould be extended to every base type, not only for orders, and bound to a table, not a ref list, so you can add subtypes dynamically and distinguish for instance different invoice type without creating new basedoctype.
** DocTax[] should be memebers of Doc class, today in factsValidate or docvalidate methods you don't have access to the whole document because doctax lines are not part of Doc class but a private member of some Doc_xxx classes without a getter. Also the DocTax class is final so you cannot extend it without touching the standard project.
** Get rid of hardcoded behaviours, like the information line displayed on StatusBar using GridTab.getTrxInfo() (we could specify a method to invoke at tab level and again a fallback to current method.
* Stay current: I mean we are in the verge of modifing the whole project for something that maybe has not surplus value, while for many years we lack to update basic components like jdbc drivers, jboss or jasper (I know we are doing it right now)
* Release often: I don't know when we are going to release the next version (360? 400?) because there is such new stuff, maybe we should have split it on subprojects and release new stable version when single projects are finalized, because the real test begin with release.
* Make the most of people: we saw that many people are willing to contribute on repetitive coding tasks, we should capitalize on that and point them to whatever the community agree on building a better Adempiere.
Just my two cents
Angelo
From Carlos post i got minor question to Victor too:
How do i see SQL full stmt that i can copy and test in TOAD or DB Editor?
If i put stop or break.. i m not sure where to get the full SQL value? I think that needs to be documented better before we proceed.
But to Carlos, i think u have to consider others point of view. Cant we leave just these few queries in? They are not many. You should have drop a word on this 2 days earlier and save me the learning curve. But anyway i learnt well from Trifon.
I hope this is frozen and i continue after the next release. Meanwhile i will help Victor to document the JPA impact for oldies and debug guide. I think that is also important Victor.
red1
Hi Redhuan,
> But to Carlos, i think u have to consider others point of view. Cant we leave just these
> few queries in? They are not many.
I asked before reverting precisely for this. I don't want to be aggressive or do something improper. I haven't reverted anything - and I'll try not to do it if there are good reasons to not do it.
> You should have drop a word on this 2 days earlier and save me the learning curve.
2 days before I didn't saw the magnitude of the changes, just after I started seeing a commit - a fix for previous commit, then a new commit, then a fix for the previous commit. I became alarmed. Sorry for not catching the impact before.
Victor,
> Carlos I ask you why do you not stop this improve when Teo and me made commit
> with Query Class in Libero and other class core if you are the guardian of
> stable, Now that we using this API the way intensive you do not agree.
Same answer as before - changing one class is a thing - changing the whole adempiere is another. This is going against libero stabilization - the changes you and Teo did were within the libero stabilization goal.
But anyways - I even said something privately to Teo that can shock many people here - but I'll dare to throw it here:
- 310 to 320 the goal was stabilization - so we fixed more than 300 bugs from compiere days.
- 320 to 340 the goal was extensibility - so we changed a lot the core and added lot of extensibility options - but we didn't advance functionally
- 340 to 400 the goal is new functionality - this represents a big jump functionally speaking (manufacturing - payroll - fixed assets - gosh we're brave!).
What I said to Teo is that 340 to 400 would be a lot easier if we have frozen core - this is - just focus on stabilization of new functionalities - and leave the core still.
That would make the stabilization work easier. Now we have added lots of unstabilizing things - and we keep adding them (that's why I called to set a freeze date).
Regards,
Carlos Ruiz