Re: you might want to look at this.....

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: you might want to look at this.....

David E Jones

Hans,

I reviewed this briefly when I saw the commit come in and didn't see  
anything troubling.

I'm glad you pinged me on it though because while reading over the  
code a little more it is clear that restricting to a remove by primary  
key will break in certain circumstances, ie the removeByAnd operations  
on the source server won't propagate.

I looked at the code that makes these values and it explicitly puts  
the stamp fields in (EntitySyncContext.java, line 646). That code was  
probably added after this remove propagate code was implemented, and  
is probably for something else so we don't want to remove it.

The best fix for this would be to remove those fields from the Map  
before calling the removeByAnd.

-David


On Jan 30, 2008, at 9:05 PM, Hans Bakker wrote:

>
>
> From: [hidden email]
> Date: January 30, 2008 8:59:59 PM MST
> To: [hidden email]
> Subject: svn commit: r616995 - /ofbiz/trunk/framework/entityext/src/
> org/ofbiz/entityext/synchronization/EntitySyncServices.java
> Reply-To: [hidden email]
>
>
> Author: hansbak
> Date: Wed Jan 30 19:59:59 2008
> New Revision: 616995
>
> URL: http://svn.apache.org/viewvc?rev=616995&view=rev
> Log:
> Entity sync did not work for deletes because the timestamps of the  
> deleted record where also checked to be the same as the original  
> record, this however was never true, even not after the copy of the  
> complete database. Now the deleted record is only checked for the  
> primary key.
>
> Modified:
>    ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
> synchronization/EntitySyncServices.java
>
> Modified: ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
> synchronization/EntitySyncServices.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncServices.java?rev=616995&r1=616994&r2=616995&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
> synchronization/EntitySyncServices.java (original)
> +++ ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
> synchronization/EntitySyncServices.java Wed Jan 30 19:59:59 2008
> @@ -216,8 +216,12 @@
>
>                 // check to see if it exists, if so remove and  
> count, if not just count already removed
>                 // always do a removeByAnd, if it was a removeByAnd  
> great, if it was a removeByPrimaryKey, this will also work and save  
> us a query
> +                // however....removeByAnd also checks for the  
> updateTimestamps....and they never match....so i changed it to  
> remove primary key and only check for the primary key.....(hansbak)
>                 pkToRemove.setIsFromEntitySync(true);
> -                int numRemByAnd =  
> delegator.removeByAnd(pkToRemove.getEntityName(), pkToRemove);
> +
> +                // Debug.logInfo("try to remove: " +  
> pkToRemove.getEntityName() + " key: " + pkToRemove.getPrimaryKey(),  
> module);
> +
> +                int numRemByAnd =  
> delegator.removeByPrimaryKey(pkToRemove.getPrimaryKey());
>                 if (numRemByAnd == 0) {
>                     toRemoveAlreadyDeleted++;
>                 } else {
> @@ -234,6 +238,7 @@
>             result.put("toStoreNotUpdated", new  
> Long(toStoreNotUpdated));
>             result.put("toRemoveDeleted", new Long(toRemoveDeleted));
>             result.put("toRemoveAlreadyDeleted", new  
> Long(toRemoveAlreadyDeleted));
> +            if (Debug.infoOn()) Debug.logInfo("Finisching  
> storeEntitySyncData (" + entitySyncId + ") - [" +  
> keysToRemove.size() + "] to remove. Actually removed: " +  
> toRemoveDeleted  + " already removed: " + toRemoveAlreadyDeleted,  
> module);
>             return result;
>         } catch (GenericEntityException e) {
>             String errorMsg = "Exception saving Entity Sync Data for  
> entitySyncId [" + entitySyncId + "]: " + e.toString();
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: you might want to look at this.....

Jacques Le Roux-2
Hi Hans,

It seems this has never been addressed, right?

Thanks

Jacques


From: "David E Jones" <[hidden email]>

>
> Hans,
>
> I reviewed this briefly when I saw the commit come in and didn't see  
> anything troubling.
>
> I'm glad you pinged me on it though because while reading over the  
> code a little more it is clear that restricting to a remove by primary  
> key will break in certain circumstances, ie the removeByAnd operations  
> on the source server won't propagate.
>
> I looked at the code that makes these values and it explicitly puts  
> the stamp fields in (EntitySyncContext.java, line 646). That code was  
> probably added after this remove propagate code was implemented, and  
> is probably for something else so we don't want to remove it.
>
> The best fix for this would be to remove those fields from the Map  
> before calling the removeByAnd.
>
> -David
>
>
> On Jan 30, 2008, at 9:05 PM, Hans Bakker wrote:
>
>>
>>
>> From: [hidden email]
>> Date: January 30, 2008 8:59:59 PM MST
>> To: [hidden email]
>> Subject: svn commit: r616995 - /ofbiz/trunk/framework/entityext/src/
>> org/ofbiz/entityext/synchronization/EntitySyncServices.java
>> Reply-To: [hidden email]
>>
>>
>> Author: hansbak
>> Date: Wed Jan 30 19:59:59 2008
>> New Revision: 616995
>>
>> URL: http://svn.apache.org/viewvc?rev=616995&view=rev
>> Log:
>> Entity sync did not work for deletes because the timestamps of the  
>> deleted record where also checked to be the same as the original  
>> record, this however was never true, even not after the copy of the  
>> complete database. Now the deleted record is only checked for the  
>> primary key.
>>
>> Modified:
>>    ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>> synchronization/EntitySyncServices.java
>>
>> Modified: ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>> synchronization/EntitySyncServices.java
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncServices.java?rev=616995&r1=616994&r2=616995&view=diff
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> --- ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>> synchronization/EntitySyncServices.java (original)
>> +++ ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>> synchronization/EntitySyncServices.java Wed Jan 30 19:59:59 2008
>> @@ -216,8 +216,12 @@
>>
>>                 // check to see if it exists, if so remove and  
>> count, if not just count already removed
>>                 // always do a removeByAnd, if it was a removeByAnd  
>> great, if it was a removeByPrimaryKey, this will also work and save  
>> us a query
>> +                // however....removeByAnd also checks for the  
>> updateTimestamps....and they never match....so i changed it to  
>> remove primary key and only check for the primary key.....(hansbak)
>>                 pkToRemove.setIsFromEntitySync(true);
>> -                int numRemByAnd =  
>> delegator.removeByAnd(pkToRemove.getEntityName(), pkToRemove);
>> +
>> +                // Debug.logInfo("try to remove: " +  
>> pkToRemove.getEntityName() + " key: " + pkToRemove.getPrimaryKey(),  
>> module);
>> +
>> +                int numRemByAnd =  
>> delegator.removeByPrimaryKey(pkToRemove.getPrimaryKey());
>>                 if (numRemByAnd == 0) {
>>                     toRemoveAlreadyDeleted++;
>>                 } else {
>> @@ -234,6 +238,7 @@
>>             result.put("toStoreNotUpdated", new  
>> Long(toStoreNotUpdated));
>>             result.put("toRemoveDeleted", new Long(toRemoveDeleted));
>>             result.put("toRemoveAlreadyDeleted", new  
>> Long(toRemoveAlreadyDeleted));
>> +            if (Debug.infoOn()) Debug.logInfo("Finisching  
>> storeEntitySyncData (" + entitySyncId + ") - [" +  
>> keysToRemove.size() + "] to remove. Actually removed: " +  
>> toRemoveDeleted  + " already removed: " + toRemoveAlreadyDeleted,  
>> module);
>>             return result;
>>         } catch (GenericEntityException e) {
>>             String errorMsg = "Exception saving Entity Sync Data for  
>> entitySyncId [" + entitySyncId + "]: " + e.toString();
>>
>>
>>
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: you might want to look at this.....

hans_bakker
Jacques, to be honest with you I cannot remember.
anyway, we lost interest in the sync function and are now looking at
using the webpos on a tablet and add usage of the local storage of HTML5
for product, customer and order....

Regards,
Hans

On 06/29/2013 03:31 AM, Jacques Le Roux wrote:

> Hi Hans,
>
> It seems this has never been addressed, right?
>
> Thanks
>
> Jacques
>
>
> From: "David E Jones" <[hidden email]>
>> Hans,
>>
>> I reviewed this briefly when I saw the commit come in and didn't see
>> anything troubling.
>>
>> I'm glad you pinged me on it though because while reading over the
>> code a little more it is clear that restricting to a remove by primary
>> key will break in certain circumstances, ie the removeByAnd operations
>> on the source server won't propagate.
>>
>> I looked at the code that makes these values and it explicitly puts
>> the stamp fields in (EntitySyncContext.java, line 646). That code was
>> probably added after this remove propagate code was implemented, and
>> is probably for something else so we don't want to remove it.
>>
>> The best fix for this would be to remove those fields from the Map
>> before calling the removeByAnd.
>>
>> -David
>>
>>
>> On Jan 30, 2008, at 9:05 PM, Hans Bakker wrote:
>>
>>>
>>> From: [hidden email]
>>> Date: January 30, 2008 8:59:59 PM MST
>>> To: [hidden email]
>>> Subject: svn commit: r616995 - /ofbiz/trunk/framework/entityext/src/
>>> org/ofbiz/entityext/synchronization/EntitySyncServices.java
>>> Reply-To: [hidden email]
>>>
>>>
>>> Author: hansbak
>>> Date: Wed Jan 30 19:59:59 2008
>>> New Revision: 616995
>>>
>>> URL: http://svn.apache.org/viewvc?rev=616995&view=rev
>>> Log:
>>> Entity sync did not work for deletes because the timestamps of the
>>> deleted record where also checked to be the same as the original
>>> record, this however was never true, even not after the copy of the
>>> complete database. Now the deleted record is only checked for the
>>> primary key.
>>>
>>> Modified:
>>>     ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>> synchronization/EntitySyncServices.java
>>>
>>> Modified: ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>> synchronization/EntitySyncServices.java
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncServices.java?rev=616995&r1=616994&r2=616995&view=diff
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ======================================================================
>>> --- ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>> synchronization/EntitySyncServices.java (original)
>>> +++ ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>> synchronization/EntitySyncServices.java Wed Jan 30 19:59:59 2008
>>> @@ -216,8 +216,12 @@
>>>
>>>                  // check to see if it exists, if so remove and
>>> count, if not just count already removed
>>>                  // always do a removeByAnd, if it was a removeByAnd
>>> great, if it was a removeByPrimaryKey, this will also work and save
>>> us a query
>>> +                // however....removeByAnd also checks for the
>>> updateTimestamps....and they never match....so i changed it to
>>> remove primary key and only check for the primary key.....(hansbak)
>>>                  pkToRemove.setIsFromEntitySync(true);
>>> -                int numRemByAnd =
>>> delegator.removeByAnd(pkToRemove.getEntityName(), pkToRemove);
>>> +
>>> +                // Debug.logInfo("try to remove: " +
>>> pkToRemove.getEntityName() + " key: " + pkToRemove.getPrimaryKey(),
>>> module);
>>> +
>>> +                int numRemByAnd =
>>> delegator.removeByPrimaryKey(pkToRemove.getPrimaryKey());
>>>                  if (numRemByAnd == 0) {
>>>                      toRemoveAlreadyDeleted++;
>>>                  } else {
>>> @@ -234,6 +238,7 @@
>>>              result.put("toStoreNotUpdated", new
>>> Long(toStoreNotUpdated));
>>>              result.put("toRemoveDeleted", new Long(toRemoveDeleted));
>>>              result.put("toRemoveAlreadyDeleted", new
>>> Long(toRemoveAlreadyDeleted));
>>> +            if (Debug.infoOn()) Debug.logInfo("Finisching
>>> storeEntitySyncData (" + entitySyncId + ") - [" +
>>> keysToRemove.size() + "] to remove. Actually removed: " +
>>> toRemoveDeleted  + " already removed: " + toRemoveAlreadyDeleted,
>>> module);
>>>              return result;
>>>          } catch (GenericEntityException e) {
>>>              String errorMsg = "Exception saving Entity Sync Data for
>>> entitySyncId [" + entitySyncId + "]: " + e.toString();
>>>
>>>
>>>
>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: you might want to look at this.....

Scott Gray-2
It would be worth considering looking at integrating with something like Vend as another option. Building a well functioning mobile POS is a long and hard road to travel.

Regards
Scott

On 29/06/2013, at 2:32 PM, Hans Bakker <[hidden email]> wrote:

> Jacques, to be honest with you I cannot remember.
> anyway, we lost interest in the sync function and are now looking at using the webpos on a tablet and add usage of the local storage of HTML5 for product, customer and order....
>
> Regards,
> Hans
>
> On 06/29/2013 03:31 AM, Jacques Le Roux wrote:
>> Hi Hans,
>>
>> It seems this has never been addressed, right?
>>
>> Thanks
>>
>> Jacques
>>
>>
>> From: "David E Jones" <[hidden email]>
>>> Hans,
>>>
>>> I reviewed this briefly when I saw the commit come in and didn't see
>>> anything troubling.
>>>
>>> I'm glad you pinged me on it though because while reading over the
>>> code a little more it is clear that restricting to a remove by primary
>>> key will break in certain circumstances, ie the removeByAnd operations
>>> on the source server won't propagate.
>>>
>>> I looked at the code that makes these values and it explicitly puts
>>> the stamp fields in (EntitySyncContext.java, line 646). That code was
>>> probably added after this remove propagate code was implemented, and
>>> is probably for something else so we don't want to remove it.
>>>
>>> The best fix for this would be to remove those fields from the Map
>>> before calling the removeByAnd.
>>>
>>> -David
>>>
>>>
>>> On Jan 30, 2008, at 9:05 PM, Hans Bakker wrote:
>>>
>>>>
>>>> From: [hidden email]
>>>> Date: January 30, 2008 8:59:59 PM MST
>>>> To: [hidden email]
>>>> Subject: svn commit: r616995 - /ofbiz/trunk/framework/entityext/src/
>>>> org/ofbiz/entityext/synchronization/EntitySyncServices.java
>>>> Reply-To: [hidden email]
>>>>
>>>>
>>>> Author: hansbak
>>>> Date: Wed Jan 30 19:59:59 2008
>>>> New Revision: 616995
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=616995&view=rev
>>>> Log:
>>>> Entity sync did not work for deletes because the timestamps of the
>>>> deleted record where also checked to be the same as the original
>>>> record, this however was never true, even not after the copy of the
>>>> complete database. Now the deleted record is only checked for the
>>>> primary key.
>>>>
>>>> Modified:
>>>>    ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>>> synchronization/EntitySyncServices.java
>>>>
>>>> Modified: ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>>> synchronization/EntitySyncServices.java
>>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/synchronization/EntitySyncServices.java?rev=616995&r1=616994&r2=616995&view=diff
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> ======================================================================
>>>> --- ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>>> synchronization/EntitySyncServices.java (original)
>>>> +++ ofbiz/trunk/framework/entityext/src/org/ofbiz/entityext/
>>>> synchronization/EntitySyncServices.java Wed Jan 30 19:59:59 2008
>>>> @@ -216,8 +216,12 @@
>>>>
>>>>                 // check to see if it exists, if so remove and
>>>> count, if not just count already removed
>>>>                 // always do a removeByAnd, if it was a removeByAnd
>>>> great, if it was a removeByPrimaryKey, this will also work and save
>>>> us a query
>>>> +                // however....removeByAnd also checks for the
>>>> updateTimestamps....and they never match....so i changed it to
>>>> remove primary key and only check for the primary key.....(hansbak)
>>>>                 pkToRemove.setIsFromEntitySync(true);
>>>> -                int numRemByAnd =
>>>> delegator.removeByAnd(pkToRemove.getEntityName(), pkToRemove);
>>>> +
>>>> +                // Debug.logInfo("try to remove: " +
>>>> pkToRemove.getEntityName() + " key: " + pkToRemove.getPrimaryKey(),
>>>> module);
>>>> +
>>>> +                int numRemByAnd =
>>>> delegator.removeByPrimaryKey(pkToRemove.getPrimaryKey());
>>>>                 if (numRemByAnd == 0) {
>>>>                     toRemoveAlreadyDeleted++;
>>>>                 } else {
>>>> @@ -234,6 +238,7 @@
>>>>             result.put("toStoreNotUpdated", new
>>>> Long(toStoreNotUpdated));
>>>>             result.put("toRemoveDeleted", new Long(toRemoveDeleted));
>>>>             result.put("toRemoveAlreadyDeleted", new
>>>> Long(toRemoveAlreadyDeleted));
>>>> +            if (Debug.infoOn()) Debug.logInfo("Finisching
>>>> storeEntitySyncData (" + entitySyncId + ") - [" +
>>>> keysToRemove.size() + "] to remove. Actually removed: " +
>>>> toRemoveDeleted  + " already removed: " + toRemoveAlreadyDeleted,
>>>> module);
>>>>             return result;
>>>>         } catch (GenericEntityException e) {
>>>>             String errorMsg = "Exception saving Entity Sync Data for
>>>> entitySyncId [" + entitySyncId + "]: " + e.toString();
>
Reply | Threaded
Open this post in threaded view
|

Re: you might want to look at this.....

Pierre Smits
In reply to this post by hans_bakker
Hans,

Are you thinking of a enhancement for WebPoS regarding improvement of UIs
tailored to mobile devices? Or are you thinking of  an app on the Android
platform (and/or others) to connect to the OFBiz PoS and WebPoS
functionalities (and others)?

Pierre
Reply | Threaded
Open this post in threaded view
|

Re: you might want to look at this.....

hans_bakker
You did not keep my original message...didn't i mention there html5?

On 06/29/2013 02:35 PM, Pierre Smits wrote:
> Hans,
>
> Are you thinking of a enhancement for WebPoS regarding improvement of UIs
> tailored to mobile devices? Or are you thinking of  an app on the Android
> platform (and/or others) to connect to the OFBiz PoS and WebPoS
> functionalities (and others)?
>
> Pierre
>