Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

ADempiere OSGI edition pre-beta release

2010-12-12
2013-03-08
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-12

    ADempiere has undergone serious refactoring thanks to the community, starting with Andreas Schimdt, then Joerg Viola and now Low Heng Sin is nearing wrapping a good enough version of 360LTS running on rails in the form of OSGI plugins. Before his beta release in a matter of days, I am releasing a pre-beta version of which i have reviewed and tested to work without serious error so far, so that the rest of the community can apply for heavy testing faster to uncover and report any hitch it might have prior to the first beta release.

    Please collect the adempiere-server folder from http://sourceforge.net/projects/adempiere/files/ADempiere%20Snapshot%20Release/OSGI-adempiere-server.zip/download

    and the adempiere-client from http://sourceforge.net/projects/adempiere/files/ADempiere%20Snapshot%20Release/OSGI-adempiere-client.zip/download

    Just expand them and replace the properties files (Adempiere.properties and AdempierEenv.properties with copies from your present 360LTS home) In the client folder  execute 'adempiere-client.sh or bat' and in the server folder you run 'adempiere-server.sh or bat'. Turn off your own new ModelValidator if any, just for this test as the OSGI may not have your MVs yet.

    OSGI means full modularity via components that are loosely coupled, having Events working alongside or replacing ModelValidators, Eclipse like behaviour, capability of Declared Services for faster and low-cost maintenance of new addons, usage of extensions for DB connections.

    For more background please see http://www.adempiere.com/index.php/OSGI_HengSin#Launching_from_Binary

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-12

    After testing the OSGI apps, you can resume back to your working instance by just going back to your ADempiere_Home and RUN_Adempiere. But your DB connection may be void, just click on the DB connection icon in the login and select back your DB Type, put in your DB Host and DB Name. Then click OK. You are back to business.

    Remember - this is an open source project. Do not use for business without support contract from a capable and reputable ADempiere provider or contractor.

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-12

    Alternatively, just RUN_silentsetup if you don't want to put in the DB values again.

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-28

    I have searched for reference info on UUID in our forums but cant find much so i make a page to introduce http://www.adempiere.com/index.php/OSGI_HengSin/UUID_Generator.

    It should be tested on non-production and we like to see how it resolves some age old issues of migration and replication.

     
  • Mario Calderon
    Mario Calderon
    2010-12-28

    Hi red1,
    thanks for the UUID link.

    Does this mean that
    - we can replace the 10-digit ID with this 36-digit right now?
    - this 36-digit ID is unique for the Adempiere universe?
    - ad_sequence has to  be replaced by a single record which manages all tables?

    And one last question: what does the process to the existing IDs, like 1234567?

    Best regards,
    Mario Calderon

     
  • Heng Sin
    Heng Sin
    2010-12-28

    Hi Mario,

    1.  we can replace the 10-digit ID with this 36-digit right now?
    In the current implementation, the UUID column is only used as an alternate key and coexists with the existing ID column. We can do away with the ID column in future but I believe it is safer and easier  that we can have them coexists for at least one release and we can decide after that.

    2. this 36-digit ID is unique for the Adempiere universe?
    Yes, UUID is globally unique by definition.

    3. ad_sequence has to  be replaced by a single record which manages all tables?
    If we only use UUID, we don't need a replacement for ad_sequence. UUID is a random number that is generated with algorithm that would make sure it is unique without any input from the DB.

    4. what does the process to the existing IDs, like 1234567?
    Please refer to my answer for 1 above.

    Hope this help.

    Regards,
    Low

     
  • rsashka
    rsashka
    2010-12-28

    Hi

    We can do away with the ID column in future but I believe it is safer and easier that we can have them coexists for at least one release and we can decide after that.

    But what about existing applications / solutions in which Adempiere interact on the basis of ID?
    Can I reserve a range for the UUID as a key ID?
    And if another program can not handle UUID as the key and the work is based on the allocation of block numbers ID?

    Regards,
    rsashka

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-28

    I think the UUID has no instance impact. Meaning that within your instance you are always (and i think must for eternity in our project) uses the generated and controlled PKs. Just that a UUID is now shadowing any original ID so that during merging, replication or PackIn from differing and overlapping sources, there is no loss of PK-FK relationships. During Packin for example, if a new BPartner is created by say Branch X with a SO against it, the new BP has to find a new ID in your instance. Now the accompanying SO originally has to point to that BP by that ID, but now in the target DB will have trouble because it has to do an IDNameLookup (etc) to pass a Name Value to be unique into the target instance first then only obtain its local ID for its PK.

    That lies the problem as the SO will now need to remember which ID this BP has taken up in the new instance. Now with UUID, that problem does not exist. You can see from the PackOut.xml extract that it now uses UUID to communicate the relationship with each other. The PK/FK are not used because that is not important as the target instance only recreate them without regard of what they were prior. Hope this explains my take of it.

    This is based on my own understanding and limited study of Heng Sin code. HS can correct me please if needed. But i feel the Original ID regime must or should never be removed (which is supporting what HS recommends above).

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-28

    To answer more directly to Rsashka's queries (thanks for asking) based on my understanding,
    1. No problem with present applications as the UUID has no own instance impact.
    2. No, you cannot reserve any UUID because that need is not apparent when original IDs are still in use as before.
    3. No other application need to handle UUID within an operating instance. It only happens during merging of different instances' overlapping records.

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-28

    Just to add why i don't like to live alone with the UUIDs because they are quite long and unreadable by human minds and not as familiar as the common 100000s which i can understand more fairly. However in the 2Pack and merging or replication works, UUIDs are the most beautiful thing to happen :D

    But come to think of it, if UUIDs eventually replaces our PKs, it can even solve another constraint. We won't need to book any IDs anymore. It will be the end of centralised ID management. UUIDs by definition will quite never get repeated. At least one chance in 17 billion times

     
  • Hi guys.

    I have some questions about the use the UUID:

    >>alternate key and coexists with the existing

    Do you use UUID only for application dictionary table, or apply for all tables?

    We implement UUID for replication, it is the unique way that Replication functionality worked perfectly, our expertise around this was that we had modify the PO class (Persistence Engine), this way when a new record is saved the UUID is generated by Persistence Engine.

    Of course the ideal solution is move all  primary key based on integer to String 32 length, unfortunately all the current code uses an integer primary key,  so that the refectory is complex and a lot the work.

    The problems that we found are that ADempiere use SQL pure and is not used persistence engine,  ie (Import functionality), so that the solution for implement UUID in the data record is not complete because is necessary replace the pure SQL and use the Persistence Engine.

    The second issue was that ADempiere have some stables that have not primary key as (_Trl or M_ProductPrice) where can not allow a primary key.

    kind regards
    Victor Perez
    www.e-evolution.com

     
  • Heng Sin
    Heng Sin
    2010-12-29

    Hi Victor,

    It is used for all tables, not just AD tables. The PO class is modify to auto generate UUID when the table have a column with the pattern TableName_UU exists.

    Yes, direct sql update is a problem that still needs to be resolved.

    Regards,
    Low

     
  • rsashka
    rsashka
    2010-12-29

    Hi,

    Make key UUID to identify packages for 2pack, it's a great idea! At most there were many difficulties to solve the situation with the same ID.

    But it seems to me that the rest of ID keys can not be replaced by a UUID. This will entail a lot of compatibility problems.

    Is not desirable and in line 2pack identified using UUID, since they can not be controlled, and therefore can not guarantee the desired sequence of lines on import / export 2pack package. It may be necessary for the dependent of one another operation. For example a description of the data structure and data itself.

    Regards,
    rsashka

     
  • Redhuan D. Oon
    Redhuan D. Oon
    2010-12-29

    I have uploaded fresh OSGI apps that has UUID applied and tested on 2Packs which are also uploaded there. Instructions are same as top of this thread.
    The download page is http://sourceforge.net/projects/adempiere/files/OSGI/
    There is also a readme.txt to help.