problems with new entity definitions

[Si Chen-2]

     [java] 2007-03-30 11:47:59,366 (main) [      
DatabaseUtil.java:2710:ERROR] Could not create foreign key indices for
entity [TrackingCodeOrderReturn]: SQL Exception while executing the
following:
     [java] CREATE INDEX TKNG_CODODR_ODRTN ON
OFBIZ.TRACKING_CODE_ORDER_RETURN (ORDER_ID)
     [java] Error was: java.sql.SQLException: Index 'TKNG_CODODR_ODRTN'
already exists in Schema 'OFBIZ'.
     [java] 2007-03-30 11:47:59,382 (main) [      
DatabaseUtil.java:2710:ERROR] Could not create foreign key indices for
entity [TrackingCodeOrderReturn]: SQL Exception while executing the
following:
     [java] CREATE INDEX TKNG_CODODR_TKCD ON
OFBIZ.TRACKING_CODE_ORDER_RETURN (TRACKING_CODE_ID)
     [java] Error was: java.sql.SQLException: Index 'TKNG_CODODR_TKCD'
already exists in Schema 'OFBIZ'.
     [java] 2007-03-30 11:47:59,398 (main) [      
DatabaseUtil.java:2710:ERROR] Could not create foreign key indices for
entity [TrackingCodeOrderReturn]: SQL Exception while executing the
following:
     [java] CREATE INDEX TKNG_CODODR_TYP ON
OFBIZ.TRACKING_CODE_ORDER_RETURN (TRACKING_CODE_TYPE_ID)
     [java] Error was: java.sql.SQLException: Index 'TKNG_CODODR_TYP'
already exists in Schema 'OFBIZ'.

[Anil Patel]

I'll look into this.

Regards
Anil

On 3/30/07, Si Chen <[hidden email]> wrote:

>
>      [java] 2007-03-30 11:47:59,366 (main) [
> DatabaseUtil.java:2710:ERROR] Could not create foreign key indices for
> entity [TrackingCodeOrderReturn]: SQL Exception while executing the
> following:
>      [java] CREATE INDEX TKNG_CODODR_ODRTN ON
> OFBIZ.TRACKING_CODE_ORDER_RETURN (ORDER_ID)
>      [java] Error was: java.sql.SQLException: Index 'TKNG_CODODR_ODRTN'
> already exists in Schema 'OFBIZ'.
>      [java] 2007-03-30 11:47:59,382 (main) [
> DatabaseUtil.java:2710:ERROR] Could not create foreign key indices for
> entity [TrackingCodeOrderReturn]: SQL Exception while executing the
> following:
>      [java] CREATE INDEX TKNG_CODODR_TKCD ON
> OFBIZ.TRACKING_CODE_ORDER_RETURN (TRACKING_CODE_ID)
>      [java] Error was: java.sql.SQLException: Index 'TKNG_CODODR_TKCD'
> already exists in Schema 'OFBIZ'.
>      [java] 2007-03-30 11:47:59,398 (main) [
> DatabaseUtil.java:2710:ERROR] Could not create foreign key indices for
> entity [TrackingCodeOrderReturn]: SQL Exception while executing the
> following:
>      [java] CREATE INDEX TKNG_CODODR_TYP ON
> OFBIZ.TRACKING_CODE_ORDER_RETURN (TRACKING_CODE_TYPE_ID)
>      [java] Error was: java.sql.SQLException: Index 'TKNG_CODODR_TYP'
> already exists in Schema 'OFBIZ'.
>

[Shi Yusen]

Hi list,

I want to use a catalog named in Chinese. The creation is OK. But when
click the link
of /catalog/control/EditProdCatalog?prodCatalogId=ChineseCatalogName on
Catalog Main page, there's an error said "Could not Find Product Catalog
with Id". I think it's because ProductCatalogId is not
escaped/unescaped. I searched the code and could not find
escape/unescape method.

If there are no such methods, I'll add them.

Did I miss something?

TIA,

Shi Yusen/Beijing Langhua Ltd.

[David E Jones]

HTTP in general is NOT capable of UTF-8 arguments, and you should  
always stick with ISO-8859(-1) characters for that. For OFBiz this  
means no *Id fields should have more general, ie UTF-8 or whatever,  
characters.

There are quite a few good discussions on this in the OFBiz mailing  
list archives, and hundreds of general discussions and information  
pages about it around the internet and even in various RFCs.

-David


On Mar 31, 2007, at 4:48 AM, Shi Yusen wrote:

> Hi list,
>
> I want to use a catalog named in Chinese. The creation is OK. But when
> click the link
> of /catalog/control/EditProdCatalog?
> prodCatalogId=ChineseCatalogName on
> Catalog Main page, there's an error said "Could not Find Product  
> Catalog
> with Id". I think it's because ProductCatalogId is not
> escaped/unescaped. I searched the code and could not find
> escape/unescape method.
>
> If there are no such methods, I'll add them.
>
> Did I miss something?
>
> TIA,
>
> Shi Yusen/Beijing Langhua Ltd.
>
>

[Shi Yusen]

Hi David,

> HTTP in general is NOT capable of UTF-8 arguments, and you should  
> always stick with ISO-8859(-1) characters for that.
Yes, that's true.

> For OFBiz this  
> means no *Id fields should have more general, ie UTF-8 or whatever,  
> characters.
OK, I'll keep this as a rule of OFBiz.

Thanks,

Shi Yusen/Beijing Langhua Ltd.

[David E Jones]

BTW, if this is necessary there are things we can do in certain parts  
of the system, like using the 0x style encoding for UTF-8 characters  
and then decoding the parameters as they come in. For most pages in  
OFBiz this could even be done in generic places in the framework  
rather than per-page or something, but it hasn't been done yet.

-David


On Mar 31, 2007, at 9:45 AM, Shi Yusen wrote:

> Hi David,
>
>> HTTP in general is NOT capable of UTF-8 arguments, and you should
>> always stick with ISO-8859(-1) characters for that.
> Yes, that's true.
>
>> For OFBiz this
>> means no *Id fields should have more general, ie UTF-8 or whatever,
>> characters.
> OK, I'll keep this as a rule of OFBiz.
>
> Thanks,
>
> Shi Yusen/Beijing Langhua Ltd.
>
>

[Shi Yusen]

> BTW, if this is necessary there are things we can do in certain parts  
> of the system, like using the 0x style encoding for UTF-8 characters  
> and then decoding the parameters as they come in.
Yes, this will work. Some functions such as search may have to contain
unicode characters in url parameters. BTW, % is also a useful pattern.

> For most pages in  
> OFBiz this could even be done in generic places in the framework  
> rather than per-page or something, but it hasn't been done yet.
I'll try to study this later when I have a good understanding on the
widget. Currently some of the getting-parameter impletements are
scattered in beanshell files. Do you mean this program style will be
changed in the future?

Kind Regards,

Shi Yusen/Beijing Langhua Ltd.

[PhantomsHorridC]

unsubscribe

 
---------------------------------
 What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.

[jonwimp]

David,

I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data
Model book. Chris Howe described some issues caused by using the Product.productId under some
circumstances, and they seems closely related to this.

HTTP should support characters 0-9. Is there any language in the world that doesn't use 0-9 but
something else instead?

Jonathon

David E. Jones wrote:

>
> HTTP in general is NOT capable of UTF-8 arguments, and you should always
> stick with ISO-8859(-1) characters for that. For OFBiz this means no *Id
> fields should have more general, ie UTF-8 or whatever, characters.
>
> There are quite a few good discussions on this in the OFBiz mailing list
> archives, and hundreds of general discussions and information pages
> about it around the internet and even in various RFCs.
>
> -David
>
>
> On Mar 31, 2007, at 4:48 AM, Shi Yusen wrote:
>
>> Hi list,
>>
>> I want to use a catalog named in Chinese. The creation is OK. But when
>> click the link
>> of /catalog/control/EditProdCatalog?prodCatalogId=ChineseCatalogName on
>> Catalog Main page, there's an error said "Could not Find Product Catalog
>> with Id". I think it's because ProductCatalogId is not
>> escaped/unescaped. I searched the code and could not find
>> escape/unescape method.
>>
>> If there are no such methods, I'll add them.
>>
>> Did I miss something?
>>
>> TIA,
>>
>> Shi Yusen/Beijing Langhua Ltd.
>>
>>
>

[Shi Yusen]

Hi Jonathon,

> I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data
> Model book. Chris Howe described some issues caused by using the Product.productId under some
> circumstances, and they seems closely related to this.
I think ProductId is not discussed in this topic. There's an implicit rule: as OFBiz is a productivity application, NO EFFICIENCY of OFBiz should be lost when making any improvements :). Take it easy.

Regards,

Shi Yusen/Beijing Langhua Ltd.

[jonwimp]

Hi Shi Yusen,

You mentioned "prodCatalogId". That goes for all other fields of type id-ne, including
Product.productId?

I do agree that improvements need to be made incrementally, so we don't have to wait say a decade
before we can start using the "corrected" OFBiz. As I told Chris, I'd rather not have to
do/witness the painfully arduous task of creating say OFBiz version "ERD Corrected". It works now
for me, and that's all I need (at least until I need to put chinese characters into URLs for
lookups, but I'd use POST usually).

I'm just curious why it was done that way, that's all.

By the way, I was just thinking of importing data, and I realized I wouldn't know the primary keys
  when entering data for import if those keys were auto-incremented integer ids. Is that why all
id fields are strings instead of integers?

Maybe I'll dig into the data reader (that imports data from xml files). What happens if my data
for import omits primary key values?

Jonathon

Shi Yusen wrote:

> Hi Jonathon,
>
>> I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data
>> Model book. Chris Howe described some issues caused by using the Product.productId under some
>> circumstances, and they seems closely related to this.
> I think ProductId is not discussed in this topic. There's an implicit rule: as OFBiz is a productivity application, NO EFFICIENCY of OFBiz should be lost when making any improvements :). Take it easy.
>
> Regards,
>
> Shi Yusen/Beijing Langhua Ltd.
>
>

[cjhowe]

It is nice to have a primary key be descriptive, as it allows less
programming thought and verification to go into an application.
However that should be weighed against the dangers and limitations that
convention may put on you.  I don't think prodCatalogId or
prodCategoryId, for that matter, have as many potential pitfalls as
productId does, at least not in the limited ways they have been used
thus far. Also, any convention used for a prodCatalogId or
prodCategoryId can be discarded and not cause as large of a business
interruption as changing a convention on productId might, I would
imagine.  

Tossing my 2 cents in since my name was invoked. :-)

--- Jonathon -- Improov <[hidden email]> wrote:

> Hi Shi Yusen,
>
> You mentioned "prodCatalogId". That goes for all other fields of type
> id-ne, including
> Product.productId?
>
> I do agree that improvements need to be made incrementally, so we
> don't have to wait say a decade
> before we can start using the "corrected" OFBiz. As I told Chris, I'd
> rather not have to
> do/witness the painfully arduous task of creating say OFBiz version
> "ERD Corrected". It works now
> for me, and that's all I need (at least until I need to put chinese
> characters into URLs for
> lookups, but I'd use POST usually).
>
> I'm just curious why it was done that way, that's all.
>
> By the way, I was just thinking of importing data, and I realized I
> wouldn't know the primary keys
>   when entering data for import if those keys were auto-incremented
> integer ids. Is that why all
> id fields are strings instead of integers?
>
> Maybe I'll dig into the data reader (that imports data from xml
> files). What happens if my data
> for import omits primary key values?
>
> Jonathon
>
> Shi Yusen wrote:
> > Hi Jonathon,
> >
> >> I'm curious why Product.productId isn't a meaningless neutral
> integer as prescribed by the Data
> >> Model book. Chris Howe described some issues caused by using the
> Product.productId under some
> >> circumstances, and they seems closely related to this.
> > I think ProductId is not discussed in this topic. There's an
> implicit rule: as OFBiz is a productivity application, NO EFFICIENCY
> of OFBiz should be lost when making any improvements :). Take it
> easy.
> >
> > Regards,
> >
> > Shi Yusen/Beijing Langhua Ltd.
> >
> >
>
>