RE: [DBMS] MS SQL Server
Hi, I'm using a Oracle 9i and both BLOB and CLOB fields. OBJ automatically convert those into byte[] respectvely String fields. My concern is that it really does so since it would be much nicer if it maps them to Blob and Clob instances and does not read from the stream before actually accessing such. Regards, Mario -Original Message- From: Theo Niemeijer [mailto:[EMAIL PROTECTED] Sent: Thu 3/27/2003 3:17 PM To: OJB Users List Cc: Subject: RE: [DBMS] MS SQL Server Max, Have not tried it, sorry. My problem with CLOB fields (and BLOB fields) is that they are not really Object Oriented in JDBC: AFAIK you would have to use _streams_ for input and output wouldn't you ? (I have used BLOB's in Oracle in a previous Bea Weblogic based JSP/servlet/JDBC website project, for storing uploaded images and retrieving them lateron to write them to the webserver filesystem. I remember I had to open the uploaded file as a stream, give this stream to JDBC, and on retrieval I got a stream handle back). I would have no idea how to use this all the way through OJB, so please enlighten me on this: We use these TEXT fields in the database,and these are mapped to JDBC type LONGVARCHAR, to get the same effect as a CLOB (Character Large OBject isn't it?), namely to store arbitary long strings in the database. (By the way, we use OJB 0.9.5 with JBoss in production, and are moving to OJB 1.0rc? when we feel confident that nothing got broken in our application. So maybe support for CLOB's is different from 0.9.5, and I do not really have initimate knowledge of all the low-level parts of OJB anyway. Would OJB automatically convert a string datatype to a CLOB stream or something ?) Why would you want to use CLOB's ? By the way: This is the class descriptor for the TextBlock object: class-descriptor class=nl.casthere.uib.ojb.Textblock table=[EMAIL PROTECTED] field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=ojbConcreteClass column=ojb_concrete_class jdbc-type=VARCHAR / field-descriptor id=3 name=text column=text jdbc-type=LONGVARCHAR / /class-descriptor -Oorspronkelijk bericht- Van: Geigl Maximilian, R235 [mailto:[EMAIL PROTECTED] Verzonden: donderdag 27 maart 2003 14:51 Aan: OJB Users List Onderwerp: AW: [DBMS] MS SQL Server Hello Theo, thanks a lot for you exhaustive explanations. Just one question left (just to be sure): I cannot handle java.sql.Types.CLOB fields with the driver, I'm I right? Max -Ursprngliche Nachricht- Von: Theo Niemeijer [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 27. Mrz 2003 14:29 An: OJB Users List Betreff: RE: [DBMS] MS SQL Server We are using the Microsoft JDBC driver from the MS website. We do not have problems with it, and use it in production together with OJB for a medium-size website application with content management services. Using it with success since september 2002. There are lots of (expensive) commercial JDBC drivers for MS SQL Server 2000, but I really do not know what the difference would be. Maybe performance or scalability, but we have not experienced problems in those area's. There is an issue related to OJB: We make use of TEXT fields to circumvent the small 8000 bytes maximum row size for some columns (with some string fields the possible total size could not be guaranteed to be that under 8000 bytes) and found that we needed to create separate reference objects for those. So we have TextBlock objects. This is because MSSQL server can not (will not) do sorting or distinct on TEXT fields. Because OJB will always use all possible fields of a mapped object extent these TEXT fields gave problems, so we mapped them to seperate objects and use auto-retrieve, auto-update etc. on them so the object behaves just like it would be if the TEXT fields were part of the table. There is another issue, but that has more
Indirection table with two columns reference
Hi, Is it possible to use two columns as 'fk-pointing-to-this-class' since inserts will yield null in other column on current configuration. I cannot change the way it looks like in the database. Is my only option to use the indirection table and have it in the collection instead of having CEquipment in the CSystem? I've tried to use SYSTEMID VERKID as fk-pointing-to-this-class column but it does not work. Many Regards, Mario Collection descriptor: collection-descriptor name=equipmentInfo element-class-ref=solo.test.dataobjects.CEquipment auto-retrieve=true auto-update=false indirection-table=DTA.SYSTEMTABLE fk-pointing-to-this-class column=SYSTEMID / fk-pointing-to-element-class column=EQNUM/ /collection-descriptor Indirection table: class-descriptor class=solo.test.dataobjects.CSystemVesselMapping table=DTA.SYSTEMTABLE field-descriptor id=0 name=equipmentId column=EQNUM jdbc-type=VARCHAR nullable=false length=12 indexed=true primarykey=true / field-descriptor id=1 name=plantId column=VERKID jdbc-type=INTEGER nullable=false index=true / field-descriptor id=2 name=systemId column=SYSTEMID jdbc-type=INTEGER nullable=false index=true primarykey=true / /class-descriptor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Introspection error in PersistentFieldPropertyImpl ?
Tanks for the reply,
First of all I'm not implying that it is a OJB bug since the Introspector is within
the Sun's JDK but would the few lines be to harsh in performance and thus could not be
integrated since I think that e.g.
-- setresembleValue
is not equally readable as (in code perspecive, not e.g ide managed environments)
-- setResembleValue
and thus gets more readable code. I won't challenge the java community with that and
can accept such convention but I think latter method name for retrieving the property
is far easer to read...
I just thought it was method names started with non capital letter in the sentence e.g.
removeAll, addTail and thus properties always begins with UC letter since getter and
setter is
prepended e.g. setMachineConfig, getId
Many Regards,
Mario
-Original Message-
From: Charles Anthony [mailto:[EMAIL PROTECTED]
Sent: den 21 mars 2003 08:30
To: 'OJB Users List'
Subject: RE: Introspection error in PersistentFieldPropertyImpl ?
The Introspector and PropertyDescriptor are part of the JDK, not classes
specific to OJB.
I haven't got the JavaBean spec to hand, so I cannot categorically confirm
that it is part of the JavaBean spec; however it is definitely a convention
(widely adhered to) that the member variable of a property has a lower case
first character. It is a little more complicated when both the the first
letter and second letter are upper case - you'd have to read up on beans the
Sun site.
However, I can definitely confirm that this behaviour is not a bug.
Cheers,
Charles.
-Original Message-
From: Mario Toffia [mailto:[EMAIL PROTECTED]
Sent: 21 March 2003 07:19
To: [EMAIL PROTECTED]
Subject: Introspection error in PersistentFieldPropertyImpl ?
Hi,
I've got two methods (setter and getter) for a property in my
bean that is called 'EquipmentId' (setEquipmentId,
getEquipmentId) i.e. PersistentFieldPropertyImpl is used for
Introspection. Using the repository.xml to map it like:
field-descriptor id=3
name=EquipmentId
column=EQNUM
jdbc-type=VARCHAR indexed=true nullable=false
/
The code snippet in
PersistentFieldPropertyImpl.findPropertyDescriptor(Class
aClass, String aPropertyName) is doing the following.
info = Introspector.getBeanInfo(aClass);
pd = info.getPropertyDescriptors();
for (int i = 0; i pd.length; i++)
{
if
(pd[i].getName().equals(aPropertyName))
{
descriptor = pd[i];
break;
}
}
the getName returns the property of the bean but the first
letter is Lower Case! is it by convension or is it a bug since
setEquipmentId and getEquipmentId would yield a property named
EquipmentId not equipmentId. The more stranger is when all
letters in the setter and getter is UPPERCASE it would
correctly return the property name i.e. if setEQUIPMENTID and
getEQUIPMENTID is specified the p[i].getName() will return EQUIPMENTID!
I've changed the code snippet to:
String csWritePropertyName = set + aPropertyName;
for (int i = 0; i pd.length; i++)
{
Method meth = pd[i].getWriteMethod();
if (null != meth)
{
if (true == meth.getName().equals(csWritePropertyName))
{
descriptor = pd[i];
break;
}
}
}
if (pd[i].getName().equals(aPropertyName))
{
descriptor = pd[i];
break;
}
since Method.getName() correctly displays the method name (as
always). I've never used the Introspector but I think this is
a strange behaviour or?
Many Regards,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
RE: Introspection error in PersistentFieldPropertyImpl ?
Hi,
Thanks and I will read the specs!
Though
However, in your original message you seem to be using
PersistentFieldPropertyImpl. This class uses the field and doesn't
relate to the JavaBean spec. It's just going after field names without
regard for JavaBean properties. So if you have a property
resembleValue that uses a field called , then in the
repository.xml you'll need to refer to , *NOT* resembleValue.
If I'm not misstaken the findPropertyDescriptor uses Introspector.getBeanInfo
and then uses getPropertyDescriptors to obtain the properties of the class. I
have not provided a xxxBeanInfo class to describe the properties and thus the
Introspector will use reflection to enumerate getters and setters to construct
properties (it is here I've missed that it uses the pattern you describe).
And thus the reflection is not used to obtain the field (my conclution).
Otherwise accessing the field would probably look like this
clz.getDeclaredField(namefromrepository)
and look if null or field is returned.
Or am I completely out of the bound again?
Cheers,
Mario
-Original Message-
From: Will Jaynes [mailto:[EMAIL PROTECTED]
Sent: den 21 mars 2003 14:28
To: OJB Users List
Subject: Re: Introspection error in PersistentFieldPropertyImpl ?
Mario,
It would be instructive for you to read the JavaBean spec at
http://java.sun.com/products/javabeans/docs/spec.html
Particularly section 8.2 Overview of Design Patterns. Here it describes
the conventions concerning propery names and names of the setter/getter
for a property. By those conventions, if your property is named
resembleValue then the getter/setter methods are called
setResembleValue and getResembleValue.
Also keep in mind, the property name has nothing to do with the field
that the property may use to store it's value. The property
resembleValue may use a field called , or it may be more
complicated and not have just one field. In any case, those are
implementation details that are hidden by the getter/setter.
However, in your original message you seem to be using
PersistentFieldPropertyImpl. This class uses the field and doesn't
relate to the JavaBean spec. It's just going after field names without
regard for JavaBean properties. So if you have a property
resembleValue that uses a field called , then in the
repository.xml you'll need to refer to , *NOT* resembleValue.
Will
Mario Toffia wrote:
Tanks for the reply,
First of all I'm not implying that it is a OJB bug since the Introspector is within
the Sun's JDK but would the few lines be to harsh in performance and thus could not
be integrated since I think that e.g.
-- setresembleValue
is not equally readable as (in code perspecive, not e.g ide managed environments)
-- setResembleValue
and thus gets more readable code. I won't challenge the java community with that and
can accept such convention but I think latter method name for retrieving the
property is far easer to read...
I just thought it was method names started with non capital letter in the sentence
e.g.
removeAll, addTail and thus properties always begins with UC letter since getter and
setter is
prepended e.g. setMachineConfig, getId
Many Regards,
Mario
-Original Message-
From: Charles Anthony [mailto:[EMAIL PROTECTED]
Sent: den 21 mars 2003 08:30
To: 'OJB Users List'
Subject: RE: Introspection error in PersistentFieldPropertyImpl ?
The Introspector and PropertyDescriptor are part of the JDK, not classes
specific to OJB.
I haven't got the JavaBean spec to hand, so I cannot categorically confirm
that it is part of the JavaBean spec; however it is definitely a convention
(widely adhered to) that the member variable of a property has a lower case
first character. It is a little more complicated when both the the first
letter and second letter are upper case - you'd have to read up on beans the
Sun site.
However, I can definitely confirm that this behaviour is not a bug.
Cheers,
Charles.
-Original Message-
From: Mario Toffia [mailto:[EMAIL PROTECTED]
Sent: 21 March 2003 07:19
To: [EMAIL PROTECTED]
Subject: Introspection error in PersistentFieldPropertyImpl ?
Hi,
I've got two methods (setter and getter) for a property in my
bean that is called 'EquipmentId' (setEquipmentId,
getEquipmentId) i.e. PersistentFieldPropertyImpl is used for
Introspection. Using the repository.xml to map it like:
field-descriptor id=3
name=EquipmentId
column=EQNUM
jdbc-type=VARCHAR indexed=true nullable=false
/
The code snippet in
PersistentFieldPropertyImpl.findPropertyDescriptor(Class
aClass, String aPropertyName) is doing the following.
info = Introspector.getBeanInfo(aClass);
pd = info.getPropertyDescriptors();
for (int i = 0; i pd.length; i++)
{
if
(pd[i].getName().equals
Introspection error in PersistentFieldPropertyImpl ?
Hi,
I've got two methods (setter and getter) for a property in my bean that is called
'EquipmentId' (setEquipmentId, getEquipmentId) i.e. PersistentFieldPropertyImpl is
used for Introspection. Using the repository.xml to map it like:
field-descriptor id=3
name=EquipmentId
column=EQNUM
jdbc-type=VARCHAR indexed=true nullable=false
/
The code snippet in PersistentFieldPropertyImpl.findPropertyDescriptor(Class aClass,
String aPropertyName) is doing the following.
info = Introspector.getBeanInfo(aClass);
pd = info.getPropertyDescriptors();
for (int i = 0; i pd.length; i++)
{
if (pd[i].getName().equals(aPropertyName))
{
descriptor = pd[i];
break;
}
}
the getName returns the property of the bean but the first letter is Lower Case! is it
by convension or is it a bug since setEquipmentId and getEquipmentId would yield a
property named EquipmentId not equipmentId. The more stranger is when all letters in
the setter and getter is UPPERCASE it would correctly return the property name i.e. if
setEQUIPMENTID and getEQUIPMENTID is specified the p[i].getName() will return
EQUIPMENTID!
I've changed the code snippet to:
String csWritePropertyName = set + aPropertyName;
for (int i = 0; i pd.length; i++)
{
Method meth = pd[i].getWriteMethod();
if (null != meth)
{
if (true == meth.getName().equals(csWritePropertyName))
{
descriptor = pd[i];
break;
}
}
}
if (pd[i].getName().equals(aPropertyName))
{
descriptor = pd[i];
break;
}
since Method.getName() correctly displays the method name (as always). I've never used
the Introspector but I think this is a strange behaviour or?
Many Regards,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
