[OFBiz] Dev - Oracle CLOBs

Wed Sep 22 20:45:08 EDT 2004

Anton,

If you write it for 2.1 I will consider merging it to 3.0, or at least 
keep it around in the issue tracker so that when someone needs it who 
can sponsor the merge comes along we can take advantage of it...

I don't know what your needs are in Jira, but I would certainly 
recommend updating to something newer, probably all the way to the 
current SVN version since I have just finished some new additions and a 
bunch of bug fixes from testing the Entity Engine.

There are all sorts of new features, dynamic view entities and 
condition based finding and a new more advanced and flexible 
auto-clearing cache and time-based synchronization to push/pull data 
to/from other servers and various speed improvements and support for 
more databases and all sorts of cool stuff. It has REALLY come a long 
way in the last year and a half or so.

-David

On Sep 22, 2004, at 3:13 AM, Anton Mazkovoi wrote:

> Hi David,
>
> Thank you for the quick reply! And sorry I took my time :(
>
> I am glad you are finding JIRA useful. I tried to do a "quick fix" for
> you regarding the time tracking being reported in hours, however it
> turned out to be a bit more complex then originally anticipated. The
> formatting code is used from a number of places and cannot be simply
> changed. For example, to display the next time a filter subscription
> will run, etc. If you do not mind everything always being reported in
> hours I can do the quick and dirty fix. Otherwise I have raised the
> issue on-line:
> http://jira.atlassian.com/browse/JRA-4628
>
> Please "watch" the issue to be notified with updates.
>
> Regarding Oracle code, thank you for the information you have provided.
> I think we will be happy to tackle implementing Oracle specific code in
> the next 3-4 weeks. I will probably code against ofbiz 2.1 as I am not
> aware of any major reasons to upgrade to 3.0 (unless you can identify a
> few? - we are only using the entity engine). Will you be interested in
> merging the code to 3.0?
>
> Thanks a lot again,
> Anton
>
>
> On Sat, 2004-09-18 at 16:05, David E. Jones wrote:
>> Anton,
>>
>> Your last statements are correct: the JDBC driver from Oracle does not
>> fully implement the JDBC spec, so you have to use the Oracle specific
>> classes. Why let some pesky standard from some little hardware company
>> get in the way of a multi-decade tradition of vendor lock-in tactics?
>> ;)
>>
>> When we work with Oracle we highly recommend using the Data Direct
>> drivers for 2 reasons:
>>
>> 1. full JDBC implementation for Oracle
>> 2. MUCH more stable for long transactions and large chunks of data
>>
>> In #2 I'm referring to semi-random connection loss in the Oracle JDBC
>> drivers that causes transactions to roll-back, etc.
>>
>> And besides, if you can afford to deploy Oracle, chances are you can
>> also afford the Data Direct JDBC drivers....
>>
>> On the other hand, it would be nice to have the Oracle specific code 
>> as
>> an option in OFBiz, but to do date none of our clients have wanted to
>> pay for that (especially given the problems with #2 that this probably
>> wouldn't solve). If anyone has done such customization, I'd be happy 
>> to
>> work with them on getting it into our current source base.
>>
>> BTW, yes we are using JIRA now to manage OFBiz, and tasks for various
>> of our clients as well. It is a nice product, so thank you to you too.
>> Though, I must admit there are a few little details that could be
>> improved to make it more useful for task management rather than just
>> issue management and such... Also, who decided to display time in 
>> terms
>> of weeks or days instead of just plain hours? Maybe it's a best
>> practice to do it that way, but Andy and I almost always convert these
>> numbers to plain hours as we are talking (based on 8 hrs/day, 5
>> days/wk), because who works an 8 hour day and a 5 day week? My paid
>> week especially is way less than that, while my working week is
>> typically way more than that...
>>
>> -David
>>
>>
>> On Sep 17, 2004, at 5:20 AM, Anton Mazkovoi wrote:
>>
>>> Hi,
>>>
>>> I know that this issue has come up a few times in the past. However,
>>> all
>>> the information I could find in the ofbiz mailing list archives and 
>>> the
>>> web seems to be quite dated and inconclusive.
>>>
>>> I work for Atlassian and we develop an issue tracker JIRA (which I
>>> believe is actually used by ofbiz for issue management).
>>>
>>> Due to ofbiz entity engine's great portability JIRA is able to run on
>>> almost any relational database. So, thanks guys!!!
>>>
>>> However we have a very annoying problem when it comes to storing long
>>> text fields in Oracle, as the varchar fields in Oracle seem to be
>>> restricted to 4000 characters. As far as I know the correct way to 
>>> get
>>> around this issue is to use Oracle's CLOBs. Is this so? Or are there
>>> any
>>> other options?
>>>
>>> Ideally we would like the issue to be resolved inside entity engine, 
>>> so
>>> that we would not have to write database (Oracle) specific code in 
>>> JIRA
>>> itself. That is, if running with Oracle the GenericValues "very-long"
>>> fields, are populated with CLOB's data and stored into CLOB 
>>> "columns".
>>>
>>> I believe this issue has been addressed by Spring by writing a
>>> "special"
>>> Hibernate plugin.
>>>
>>> Is this possible in OfBiz? If so, which release?
>>>
>>>> From my limited research, I can see that some attempt to do this has
>>> been made in ofbiz 3.0 (we are still using 2.1). The
>>> org.ofbiz.entity.jdbc.SqlJdbcUtil getValue method seems to test for
>>> CLOB
>>> database type and then read the stream the CLOB contents in. 
>>> However, I
>>> cannot find code that actually populates a CLOB in a similar manner.
>>> There is some commented out code in 
>>> org.ofbiz.entity.jdbc.SQLProcessor
>>> setValue(String field) method. However, it is commented out :)
>>>
>>> The fieldtypeoracle.xml has the database type of "very-long" set to
>>> CLOB. Does this actually work when storing values? (I have to admit, 
>>> I
>>> have not tried using ofbiz 3.0 yet. I just wanted to do some
>>> researching
>>> before going with the upgrade).
>>>
>>> Also, the code in org.ofbiz.entity.jdbc.SqlJdbcUtil seems to use
>>> standard javax.sql method of reading CLOBs. The Spring utility,
>>> mentioned above, had to resort to using Oracle specific methods for
>>> reading CLOB,s as apparently the drivers do not conform to the JDBC
>>> spec
>>> properly. Can anyone confirm this?
>>>
>>> Also, the page:
>>> http://ofbizwiki.go-integral.com/Wiki.jsp?page=OracleDatabase
>>> suggests using Data Direct Oracle JDBC drivers. Do these drivers
>>> transparently populate CLOBs?
>>>
>>> Any information and comments are very much appreciated!
>>>
>>> Thanks,
>>> Anton
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.ofbiz.org
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>> ______________________________________________________________________
>>  _______________________________________________
>> Dev mailing list
>> Dev at lists.ofbiz.org
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2363 bytes
Desc: not available
Url : http://lists.ofbiz.org/pipermail/dev/attachments/20040922/69011282/smime.bin