Re: Move buildbot messages out of DEV mailing lists

[Jacques Le Roux]

Hi,

As I thought, it was not an issue in our script but effectively an infra issue

So we still have repetitive success, or failure, reports, when it should be 
only triggered on state changes .

I have created INFRA-15394 for that

Jacques


Le 24/10/2017 à 13:21, Jacques Le Roux a écrit :

I tried a small fix, let's see

If it does not work, the best is to fill at request here 
https://issues.apache.org/jira/servicedesk/customer/portal/1/create/3

In the meantime you could create a specific buildbot folder in your email client and a rule to send buildbot emails there (mails come from 
build...@apache.org, easy)


Jacques


Le 24/10/2017 à 12:57, Taher Alkhateeb a écrit :

Buildbot messages should not be too many, having that many is a faulty
implementation (false positives)

So, perhaps we shouldn't necessarily move the notifications away,
instead, we should fix the buildbot scripts.

On Tue, Oct 24, 2017 at 1:32 PM, James Yong  wrote:

Hi all,

The Buildbot messages are filling considerable spaces in the DEV mailing list.
Wonder if we should move them elsewhere...

Regards,
James Yong

Re: Tracking Data Model changes

[Aditya Sharma]

Hello all,

I have created a ticket here
.

I will be adding information about data model changes between OFBiz.9 to
OFBiz.17.11 in the initial file.

As commented on the ticket,

The file will have the format:


Entity Changes:

Here we will have a bulleted list with entity names and the revision number
1. Added Entities
2. Removed Entities


Field changes:

Here we will show data in tabular form in following format:

entityname | field | action | isPK | revision


Any suggestions are warmly welcomed.

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Thu, Oct 12, 2017 at 3:02 AM, Michael Brohl 
wrote:

> +1 for tracking datamodel changes together with data migration scripts
>
> In our customer projects, we track every change in a simple text file in
> the source code repository. It contains description of the changes,
> references to issues or requirement documentation and SQL scripts for
> migrations.
>
> In OFBiz, we should at least provide SQL scripts for the embedded Derby
> database, maybe there will be contributions for other databases as well.
>
> Something like db-changelog.derby.txt, db-changelog.mysql.txt or similar.
>
> Cheers,
>
> Michael
>
> Am 31.08.17 um 12:32 schrieb Taher Alkhateeb:
>
> Hi Ashish,
>>
>> With respect to Jacques' question, I kind of already answered in that
>> it is not only documentation but also automation.
>>
>> Now with respect to which releases to incorporate, it really depends
>> on what the community decides. I would personally prefer to not go any
>> earlier than 13, or preferably just 16 to trunk, which means we design
>> this solution for the future, not necessarily the past. The powerful
>> thing in using something like liquibase is that not only do you change
>> the schema (the entity engine can do that partially) but you also
>> decide on how to migrate the existing data to the new schema. For
>> example, you might need to split a field to two, or merge two fields,
>> and so on and so forth.
>>
>> Anyway, this is only an idea if people are interested in it. The
>> original idea of just documenting is also perfectly reasonable and
>> beneficial.
>>
>> On Thu, Aug 31, 2017 at 8:11 AM, Ashish Vijaywargiya
>>  wrote:
>>
>>> +1, Taher. I will wait for your comment on Jacques question, we already
>>> have a document but I think the automated script that can be implemented
>>> here. Liquidbase and flyway seem to be promising solutions!
>>>
>>> One question always comes to my mind: Can we say that automated scripts
>>> will support the migration from last two or at max three known releases?
>>> I think we should not put the effort in building the migration script
>>> that
>>> could migrate ofbiz earlier version(Let's say Ofbiz 10 or 9 or 4) to the
>>> latest version. Please share your thoughts on this.
>>>
>>> Kind Regards
>>> Ashish Vijaywargiya
>>> HotWax Systems - est. 1997 
>>>
>>>
>>> On Wed, Aug 30, 2017 at 7:54 PM, Taher Alkhateeb <
>>> slidingfilame...@gmail.com
>>>
 wrote:
 Good idea! Why not take it a step further, and write data migration
 scripts? They will serve two purposes in one: 1) document changes 2)
 automate upgrades.

 You can experiment with solutions like liquibase or flyway

 On Aug 30, 2017 4:23 PM, "Aditya Sharma" >>> om>
 wrote:

 Hello everyone,

 For one of my assignments, I need to find out entity changes that took
 place between an older release and the latest release.

 One of the solutions that came up was comparing the database using MySQL
 Workbench or some other utility. I found around 60+ new entity changes
 and
 a lot of minor field changes since last big book was published (OFBiz 9
 I
 suppose).
 It's fascinating for me that around 8 years passed since then and data
 model still stands well (Kudos to Universal Data Model that we followed
 in
 OFBiz)


 Just a proposal, since we don't have so many frequent changes in the
 data
 model. It will be good to have a page or some other method defined to
 keep
 a track of such changes.

 I feel such information can be quite helpful when migrating from an
 older
 to some newer release.

 Please share your thoughts.

 Thanks and Regards,

 *Aditya Sharma* | Enterprise Software Engineer
 HotWax Systems 
 


>
>

RE: RE: RE: RE: Quantity missing for inventory transfer records

[Swapnil Shah]

Thanks all your suggestions.
I think similarity of the discussed requirements with ordering flow lead to
the suggestions to use Order model. I don't have strong preference to use
one over another as long as we are able to support bulk of the discussed
requirements in this thread in a less complicated, easy to maintain and most
flexible way.

If we all are in agreement to take Inventory Transfer route then let's cut a
JIRA to proceed with it.

Thanks,
Swapnil

-Original Message-
From: James Yong [mailto:jamesy...@apache.org]
Sent: Wednesday, October 25, 2017 8:27 PM
To: dev@ofbiz.apache.org
Subject: Re: RE: RE: RE: Quantity missing for inventory transfer records

Hi all,

Having suggested possible entity changes to both approaches (with or without
Order entity), I prefer not to make use of Order entity for inventory
transfer. Order entity is currently shared by Sales Order and Purchase
Order. Using Order for transfer may make it harder to expand inventory
transfer functionalities in the future.

We can also look at OpenTap's implementation for reference.
http://www.opentaps.org/docs/index.php/Transfer_Shipment

Regards,
James Yong

On 2017-10-25 11:43, Swapnil Shah  wrote:
> Let's keep in mind that in reality it's the same single shipment that
> needs to change hands between source and destination facility as a
> part of single operational system. If we are willing to take Order
> model route, then is it possible that we introduce a new order type
> 'Replenishment Order (RO)' or 'Transfer Order' along with new Shipment
> Type ‘Transfer Shipment’. And allow to have these ROs processed
> through this single transfer shipment.
> What it would mean is that:
>
>1. Create RO with Shipping Facility (i.e. originating
>DC/Warehouse/Store) and Receiving Facility (i.e. destination
>DC/Warehouse/Store). Possibly with same ‘Bill/Ship From Vendor’ and
>‘Bill/Ship to Customer’ party id (as long as both originating and
>destination facilities are owned by same registered company or business
>entity).
>2. Allow to selectively reserve Inventory Items against RO items (even
>if it means overriding existing reservations).
>3. Allow warehouse/facility to group all common destination RO in a
>single ‘Transfer Shipment’ during picking.
>4. Once shipment is packed/shipped from originating facility then move
>its status to ‘Shipped’. At the same time linked RO’s status can
> also be
>marked as ‘Shipped’. This should affect the on Hand to the tune of
> shipped
>units.
>5. Generate only a separate Tax Invoice (if applicable) against linked
>RO.
>6. Allow Destination Facility to ‘Receive’ the ‘Shipped’ RO
> (similar to
>PO receiving) but under the very same linked Transfer Shipment that was
>shipped from originating facility. This should affect the On hand to
> the
>tune of received units.
>7. Once whole Shipment is successfully received, move the shipment to
>‘Received’ status. And at the same time linked RO can also be
> marked as
>‘Completed’.
>8. Hit the necessary and relevant GL accounts and posting in the
> process
>wherever needed.
>
>
>
> I am not sure about level of technical changes involved against other
> suggested approaches, so please feel free to ignore if it looks over
> complicated.
>
>
>
> Thanks,
>
> Swapnil
>
>
>
> -Original Message-
> From: Vaibhav Jain [mailto:vaibhav.j...@hotwaxsystems.com]
> Sent: Tuesday, October 24, 2017 6:46 PM
> To: dev@ofbiz.apache.org
> Subject: Re: RE: RE: Quantity missing for inventory transfer records
>
>
>
> Hello All,
>
>
>
> Thanks Swapnil for the detailed business scenarios.
>
>
>
> Thanks James for the reply.
>
>
>
> I just want to convey that there is no need to use a separate data
> model for inventory transfer. We can use order data model for inventory
> transfer.
>
>
>
> We can create a SO from one facility which create an automated PO for
> another facility. Inventory transfer will be done using sales/purchase
> order.
>
>
>
> Stock move is used for intra-warehouse inventory transfer while
> inventory transfer is for inter-warehouse inventory transfer.
>
>
>
> We can achieve inventory transfer using order data model instead of
> using separate data model for inventory transfer.
>
>
>
>1. On the basis of from party and to party we can identify that
> order is
>
>transfer order(In transfer order fromParty and toParty are same).
>
>2. status of inventory transfer can be maintained in OrderStatus
> entity.
>
>3. Tax is applied or not can be configurable.
>
>4. Shipment is already associated with order data model.
>
>5. Order adjustment can be used to record adjustments.
>
>6. The Orderitem entity can be used to transfer multiple products
> at a
>
>time.
>
>7. Reservation and issuance are already working in order data model.
>
>8. The OrderContent entity can be used to attach Stock tran

Re: [SITE] Unused images in site

[Jacques Le Roux]

Thanks Deepak,

I'll do also but I feel uncomfortable because I'm unsure of which are used or 
not, some are obvious

Also next target is RAT and your related Jira

Jacques


Le 27/10/2017 à 11:16, Deepak Dixit a écrit :

+1 Agreed Jacques,

Same applies for images webapp located at common-themes/webapp/images.

I tried to cleanup code, as always I'll help on this :)

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Fri, Oct 27, 2017 at 1:55 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

We have a lot of images in https://ofbiz.apache.org/images/ and its
subdirectory

Viewing them, I guess some are now useless. If we keep all useless images
when we will update again the site it will be a mess to recognise the
images really used and to chose among them, the fewer the better.

So I suggest to remove the ones not needed

Opinions ? Volunteers ?

Jacques

RE: Updates to EntityQuery

[Gareth Carter]

Hi Paul

Problem with that, it's all or nothing. We only need this for specific use 
cases. Having forUpdate in EntityQuery gives us that flexibility. It could be 
changed to use either method which depends on the scenario you use it for
Gareth Carter
Software Development Analyst
Stannah Management Services Ltd
IT Department
Ext:
7036
DDI:
01264 364311


Please consider the environment before printing this email.

-Original Message-
From: Paul Foxworthy [mailto:p...@cohsoft.com.au]
Sent: 27 October 2017 12:42 AM
To: dev@ofbiz.apache.org
Subject: Re: Updates to EntityQuery

Hi all,

As far as I know, FOR UPDATE would only break SQLite, and I can live with that.

Gareth, would optimistic instead of pessimistic work for your situation?
The database does less of the work and it's more scalable. I haven't tested it 
out, but OFBiz provides optimistic locking if you turn on enable-lock.

Cheers

Paul Foxworthy



On 27 October 2017 at 03:49, Jacques Le Roux 
wrote:

> I agree with Scott and Taher,
>
> About your question Gareth, we once had a hard coded  "for update"
> somewhere in OFBiz code (in SequenceUtil.SequenceBank.fillBank() ).
> I put it in. Then Jacopo crossed an issue in a cluster and rightly
> changed it to something better See
> https://issues.apache.org/jira/browse/OFBIZ-2353 for more where Adrian
> gave some directions also.
>
> Since I did not read all in the thread and there is no patch yet I
> don't know if something alike applies to EntityQuery API. Putting a
> for update is certainly much simpler, so just saying for now.
>
> Jacques
>
>
>
> Le 26/10/2017 à 10:46, Gareth Carter a écrit :
>
>> HI all
>>
>> Thank for the response
>>
>> It could be considered a hint, if the underlying db does not support
>> it then don't use it. Adding an attribute on the datasource could be
>> the way to go but I also believe we need methods to tell the system
>> when to use it, you don't need it all the time only in selective cases.
>>
>> Until support is added I see ofbiz as purely RDMS. I don't believe
>> ofbiz should restrict itself on the assumption it might support
>> different databases such as nosql.
>>
>> There could be an alternative to forUpdate, anyone considered
>> implementing a distributed locking mechanism? The whole point for
>> using forUpdate is to prevent one or more code blocks changing the
>> same database records concurrently, db row locks help but are not
>> supported by all databases but an external locking mechanism may
>> provide a generic way of dealing with this. OFBiz already provides a
>> semaphore on services but I believe you need something at entity
>> level Gareth Carter Software Development Analyst Stannah Management
>> Services Ltd IT Department
>> Ext:
>> 7036
>> DDI:
>> 01264 364311
>>
>>
>> Please consider the environment before printing this email.
>>
>> -Original Message-
>> From: Taher Alkhateeb [mailto:slidingfilame...@gmail.com]
>> Sent: 26 October 2017 6:13 AM
>> To: OFBIZ Development Mailing List 
>> Subject: Re: Updates to EntityQuery
>>
>> Hmmm usually my first gut reaction would be "keep things consistent",
>> however Scott made a good argument for supporting non-common DB features.
>> So my suggestion would be to use something like the widget's
>>  tag (or equivalent in code) for any features
>> not supported in all DBMSs. By labeling it as such the user is aware
>> that the DB selection is restricted.
>>
>> Now with regards to your comment about NoSQL, such databases are
>> fundamentally different, and act more like a key-value based entities
>> without a schema or the resulting ACID properties. It is possible to
>> make it work with the entity engine, but then you'd lose the
>> flexibility it gives you because you want to restrict yourself to the
>> relational model that we apply in OFBiz. The idea of NoSQL is to
>> think at a different conceptual level of your domain model.
>>
>> On Thu, Oct 26, 2017 at 4:33 AM, Scott Gray
>> 
>> wrote:
>>
>>> I think it's better to have for-update available for use for the
>>> majority of use-cases than it is to exclude it altogether.  I'd
>>> rather lose the databases that don't support it than constrain the
>>> ones that do and are used most by pretty much everyone.  It would be
>>> nice to hear from anyone using a database that doesn't support it
>>> since I'm just guessing most of us use postgres or mysql.
>>>
>>> Has anyone actually looked at how NoSQL databases might work with
>>> the OFBiz entity engine or are the concepts too far removed from SQL
>>> for it to even be workable?
>>>
>>> If we did want to support for-update globally, we could always have
>>> the delegator simulate it by issuing an UPDATE to lock the rows
>>> prior to performing the SELECT.  Although it might not work
>>> perfectly in all cases, it could be a good compromise. e.g.
>>> UPDATE table SET lastUpdatedTxStamp = NOW() WHERE ...conditions --
>>> lock the rows SELECT * FROM table WHERE ...conditions -- select the
>>> rows
>>>
>>>

Re: [SITE] Unused images in site

[Deepak Dixit]

+1 Agreed Jacques,

Same applies for images webapp located at common-themes/webapp/images.

I tried to cleanup code, as always I'll help on this :)

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Fri, Oct 27, 2017 at 1:55 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> We have a lot of images in https://ofbiz.apache.org/images/ and its
> subdirectory
>
> Viewing them, I guess some are now useless. If we keep all useless images
> when we will update again the site it will be a mess to recognise the
> images really used and to chose among them, the fewer the better.
>
> So I suggest to remove the ones not needed
>
> Opinions ? Volunteers ?
>
> Jacques
>
>

[SITE] Unused images in site

[Jacques Le Roux]

Hi,

We have a lot of images in https://ofbiz.apache.org/images/ and its subdirectory

Viewing them, I guess some are now useless. If we keep all useless images when we will update again the site it will be a mess to recognise the images 
really used and to chose among them, the fewer the better.


So I suggest to remove the ones not needed

Opinions ? Volunteers ?

Jacques

Re: Updates to EntityQuery

[Jacopo Cappellato]

On Thu, Oct 26, 2017 at 7:13 AM, Taher Alkhateeb  wrote:

> [...] The idea of NoSQL is to think at a different conceptual level of
> your domain model.
>

I agree! In order to leverage the power of NoSQL databases you have to
write your code accordingly and apply patterns that are fundamentally
different from the ones adopted with relational databases; also, NoSQL is a
rather large group that contains different families of products that
require different handling.
For all of these reasons I don't think that porting the entity engine to a
NoSQL database, while technically possible, would be actually useful.

Jacopo