You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlbeans-user@xml.apache.org by Brian K Bonner <br...@paraware.com> on 2004/02/20 22:28:16 UTC
Plans for V2?
Eric, David, etc.
I saw someone else asked a similar question. I'm interested in hooking
XMLBeans up to Hibernate. It doesn't appear that there is a way to create
beans from a default constructor. From playing with V1, it looks like a
DOM implementation is created by the factory (which acts as the "store"
for the Java Interfaces and XML Beans handles manipulating the store
through the setters/getters. I have looked at V2, but it appears that the
bean construction is the same.
Hibernate requires default constructors to be available to create the
objects from the database.
Thanks.
- Brian
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: Plans for V2?
Posted by Brian Koehmstedt <bp...@now2000.com>.
Brian K Bonner wrote:
> Brian K., thanks for the reply.
>
> I'm curious how you're using the Interceptor to modify the instances,
> doesn't the Entity have to exist prior to the Interceptor being called?
No.
The Interceptor tells Hibernate how to instantiate objects (as well as
save/update/delete them, etc).
SessionFactory sessionFactory = config.buildSessionFactory();
XMLBeansInterceptor interceptor = new XMLBeansInterceptor();
sessionFactory.openSession(interceptor);
Then you do your retrievals and Hibernate will use the interceptor to
instantiate objects.
The XMLBeansInterceptor can look something like this:
public class XMLBeansInterceptor implements Interceptor
{
...
public Object instantiate(Class clazz, Serializable id)
{
if(org.apache.xmlbeans.XmlObject.class.isAssignableFrom(clazz))
{
Method method = clazz.getMethod(
"newInstance",
new Class[]{Integer.class});
Object obj = method.invoke(
null, new Object[]{(Integer)id}
);
return(obj);
}
return(null); // tells hibernate to use default constructor
}
...
}
(my Ids are Integers, obviously yours may be some other type)
>
> Re: primitive types, I thought Hibernate would handle wrappers (Integer,
> Boolean, Double, etc.). I do think that mapping the Calendar object is a
> bit of a challenge.
I have a XMLSchema that wraps around basic XMLSchema types. i.e., the
schema has it's own string type derived from xs:string, so XMLBeans is
returning the derived type object, not a String. So I have to wrap that
getter and call .getStringValue() on the object in order to get a String
out of it.
The same goes for types that wrap around Dates and such.
>
> Re: nillable (nullable?) XML elements, I haven't run into this problem
> just yet, but if you have
>
> <xs:element name="FirstName" type="xs:String" minOccurs="0" maxOccurs="1"
> />
> doesn't this indicate that the FirstName element doesn't have to exist. To
> me this would indicate that it is null and thus the database should
> support nulls.
>
> If you used:
> <xs:element name="FirstName" type="xs:String" minOccurs="1" maxOccurs="1"
> />
> Then, even if the user sends an empty string <FirstName/> this would be
> inserted as '' in the database. Am I incorrect in assuming this?
>
> Thanks for the interchange.
No, I'm referring to elements in the XMLSchema that have nillable="true"
set. The behavior changes, and XMLBeans seems to create empty
XmlObjects for nillable elements even if the element doesn't exist in
the XML file.
I mean:
<complexType name="myType">
<complexContent>
<extension base="parent">
<sequence>
<element name="child" minOccurs="0" nillable="true"/>
...
</sequence>
</extension>
</complexContent>
</complexType>
Then when I have an XML file with an element of myType, even if the
element does not contain the child, XMLBeans will create an empty
XMLObject when getChild() is called. Then when I try to persist the
object, Hibernate tries to save the empty object. So I have to wrap
around getChild() and check to see if it's empty.
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: Plans for V2?
Posted by Brian Koehmstedt <bp...@now2000.com>.
Brian K Bonner wrote:
> Brian K., thanks for the reply.
>
> I'm curious how you're using the Interceptor to modify the instances,
> doesn't the Entity have to exist prior to the Interceptor being called?
No.
The Interceptor tells Hibernate how to instantiate objects (as well as
save/update/delete them, etc).
SessionFactory sessionFactory = config.buildSessionFactory();
XMLBeansInterceptor interceptor = new XMLBeansInterceptor();
sessionFactory.openSession(interceptor);
Then you do your retrievals and Hibernate will use the interceptor to
instantiate objects.
The XMLBeansInterceptor can look something like this:
public class XMLBeansInterceptor implements Interceptor
{
...
public Object instantiate(Class clazz, Serializable id)
{
if(org.apache.xmlbeans.XmlObject.class.isAssignableFrom(clazz))
{
Method method = clazz.getMethod(
"newInstance",
new Class[]{Integer.class});
Object obj = method.invoke(
null, new Object[]{(Integer)id}
);
return(obj);
}
return(null); // tells hibernate to use default constructor
}
...
}
(my Ids are Integers, obviously yours may be some other type)
>
> Re: primitive types, I thought Hibernate would handle wrappers (Integer,
> Boolean, Double, etc.). I do think that mapping the Calendar object is a
> bit of a challenge.
I have a XMLSchema that wraps around basic XMLSchema types. i.e., the
schema has it's own string type derived from xs:string, so XMLBeans is
returning the derived type object, not a String. So I have to wrap that
getter and call .getStringValue() on the object in order to get a String
out of it.
The same goes for types that wrap around Dates and such.
>
> Re: nillable (nullable?) XML elements, I haven't run into this problem
> just yet, but if you have
>
> <xs:element name="FirstName" type="xs:String" minOccurs="0" maxOccurs="1"
> />
> doesn't this indicate that the FirstName element doesn't have to exist. To
> me this would indicate that it is null and thus the database should
> support nulls.
>
> If you used:
> <xs:element name="FirstName" type="xs:String" minOccurs="1" maxOccurs="1"
> />
> Then, even if the user sends an empty string <FirstName/> this would be
> inserted as '' in the database. Am I incorrect in assuming this?
>
> Thanks for the interchange.
No, I'm referring to elements in the XMLSchema that have nillable="true"
set. The behavior changes, and XMLBeans seems to create empty
XmlObjects for nillable elements even if the element doesn't exist in
the XML file.
I mean:
<complexType name="myType">
<complexContent>
<extension base="parent">
<sequence>
<element name="child" minOccurs="0" nillable="true"/>
...
</sequence>
</extension>
</complexContent>
</complexType>
Then when I have an XML file with an element of myType, even if the
element does not contain the child, XMLBeans will create an empty
XMLObject when getChild() is called. Then when I try to persist the
object, Hibernate tries to save the empty object. So I have to wrap
around getChild() and check to see if it's empty.
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: Plans for V2?
Posted by Brian K Bonner <br...@paraware.com>.
Brian K., thanks for the reply.
I'm curious how you're using the Interceptor to modify the instances,
doesn't the Entity have to exist prior to the Interceptor being called?
Re: primitive types, I thought Hibernate would handle wrappers (Integer,
Boolean, Double, etc.). I do think that mapping the Calendar object is a
bit of a challenge.
Can you elaborate on what you're referring to when you say:
[snip]
> trying to extend the XMLBeans so that Hibernate has
> the getter/setter methods it needs to map to primitive database types."
[/snip]
Re: nillable (nullable?) XML elements, I haven't run into this problem
just yet, but if you have
<xs:element name="FirstName" type="xs:String" minOccurs="0" maxOccurs="1"
/>
doesn't this indicate that the FirstName element doesn't have to exist. To
me this would indicate that it is null and thus the database should
support nulls.
If you used:
<xs:element name="FirstName" type="xs:String" minOccurs="1" maxOccurs="1"
/>
Then, even if the user sends an empty string <FirstName/> this would be
inserted as '' in the database. Am I incorrect in assuming this?
Thanks for the interchange.
- Brian B.
Brian Koehmstedt <bp...@now2000.com> wrote on 02/20/2004 04:41:41 PM:
> Brian K Bonner wrote:
> > Eric, David, etc.
> >
> > I saw someone else asked a similar question. I'm interested in
hooking
> > XMLBeans up to Hibernate. It doesn't appear that there is a way to
create
> > beans from a default constructor. From playing with V1, it looks like
a
> > DOM implementation is created by the factory (which acts as the
"store"
> > for the Java Interfaces and XML Beans handles manipulating the store
> > through the setters/getters. I have looked at V2, but it appears that
the
> > bean construction is the same.
> >
> > Hibernate requires default constructors to be available to create the
> > objects from the database.
> >
>
> Well, actually, this is the lesser of Hibernate<->XMLBeans integration
> problems, because you can use a net.sf.hibernate.Interceptor (see
> http://www.hibernate.org/hib_docs/reference/html/manipulating-data.
> html#manipulating-data-s15)
>
> to dictate how Hibernate constructs new objects.
>
> What's more hairy is trying to extend the XMLBeans so that Hibernate has
> the getter/setter methods it needs to map to primitive database types.
> I have found no way of dealing with this other than just piping the
> XMLBeans generated source through a perl script that modifies the actual
> code, then recompile the source.
>
> Also I've had problems with XMLBeans creating objects for nillable XML
> elements and Hibernate thinks it's something it needs to store in the
> database. I've had to wrap getter methods so that it checks for 0
> length strings (.getStringValue()).
>
> Everything I've done has been pretty kludgy, frankly.
>
>
>
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: Plans for V2?
Posted by Brian K Bonner <br...@paraware.com>.
Brian K., thanks for the reply.
I'm curious how you're using the Interceptor to modify the instances,
doesn't the Entity have to exist prior to the Interceptor being called?
Re: primitive types, I thought Hibernate would handle wrappers (Integer,
Boolean, Double, etc.). I do think that mapping the Calendar object is a
bit of a challenge.
Can you elaborate on what you're referring to when you say:
[snip]
> trying to extend the XMLBeans so that Hibernate has
> the getter/setter methods it needs to map to primitive database types."
[/snip]
Re: nillable (nullable?) XML elements, I haven't run into this problem
just yet, but if you have
<xs:element name="FirstName" type="xs:String" minOccurs="0" maxOccurs="1"
/>
doesn't this indicate that the FirstName element doesn't have to exist. To
me this would indicate that it is null and thus the database should
support nulls.
If you used:
<xs:element name="FirstName" type="xs:String" minOccurs="1" maxOccurs="1"
/>
Then, even if the user sends an empty string <FirstName/> this would be
inserted as '' in the database. Am I incorrect in assuming this?
Thanks for the interchange.
- Brian B.
Brian Koehmstedt <bp...@now2000.com> wrote on 02/20/2004 04:41:41 PM:
> Brian K Bonner wrote:
> > Eric, David, etc.
> >
> > I saw someone else asked a similar question. I'm interested in
hooking
> > XMLBeans up to Hibernate. It doesn't appear that there is a way to
create
> > beans from a default constructor. From playing with V1, it looks like
a
> > DOM implementation is created by the factory (which acts as the
"store"
> > for the Java Interfaces and XML Beans handles manipulating the store
> > through the setters/getters. I have looked at V2, but it appears that
the
> > bean construction is the same.
> >
> > Hibernate requires default constructors to be available to create the
> > objects from the database.
> >
>
> Well, actually, this is the lesser of Hibernate<->XMLBeans integration
> problems, because you can use a net.sf.hibernate.Interceptor (see
> http://www.hibernate.org/hib_docs/reference/html/manipulating-data.
> html#manipulating-data-s15)
>
> to dictate how Hibernate constructs new objects.
>
> What's more hairy is trying to extend the XMLBeans so that Hibernate has
> the getter/setter methods it needs to map to primitive database types.
> I have found no way of dealing with this other than just piping the
> XMLBeans generated source through a perl script that modifies the actual
> code, then recompile the source.
>
> Also I've had problems with XMLBeans creating objects for nillable XML
> elements and Hibernate thinks it's something it needs to store in the
> database. I've had to wrap getter methods so that it checks for 0
> length strings (.getStringValue()).
>
> Everything I've done has been pretty kludgy, frankly.
>
>
>
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: Plans for V2?
Posted by Brian Koehmstedt <bp...@now2000.com>.
Brian K Bonner wrote:
> Eric, David, etc.
>
> I saw someone else asked a similar question. I'm interested in hooking
> XMLBeans up to Hibernate. It doesn't appear that there is a way to create
> beans from a default constructor. From playing with V1, it looks like a
> DOM implementation is created by the factory (which acts as the "store"
> for the Java Interfaces and XML Beans handles manipulating the store
> through the setters/getters. I have looked at V2, but it appears that the
> bean construction is the same.
>
> Hibernate requires default constructors to be available to create the
> objects from the database.
>
Well, actually, this is the lesser of Hibernate<->XMLBeans integration
problems, because you can use a net.sf.hibernate.Interceptor (see
http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#manipulating-data-s15)
to dictate how Hibernate constructs new objects.
What's more hairy is trying to extend the XMLBeans so that Hibernate has
the getter/setter methods it needs to map to primitive database types.
I have found no way of dealing with this other than just piping the
XMLBeans generated source through a perl script that modifies the actual
code, then recompile the source.
Also I've had problems with XMLBeans creating objects for nillable XML
elements and Hibernate thinks it's something it needs to store in the
database. I've had to wrap getter methods so that it checks for 0
length strings (.getStringValue()).
Everything I've done has been pretty kludgy, frankly.
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: Plans for V2?
Posted by Brian Koehmstedt <bp...@now2000.com>.
Brian K Bonner wrote:
> Eric, David, etc.
>
> I saw someone else asked a similar question. I'm interested in hooking
> XMLBeans up to Hibernate. It doesn't appear that there is a way to create
> beans from a default constructor. From playing with V1, it looks like a
> DOM implementation is created by the factory (which acts as the "store"
> for the Java Interfaces and XML Beans handles manipulating the store
> through the setters/getters. I have looked at V2, but it appears that the
> bean construction is the same.
>
> Hibernate requires default constructors to be available to create the
> objects from the database.
>
Well, actually, this is the lesser of Hibernate<->XMLBeans integration
problems, because you can use a net.sf.hibernate.Interceptor (see
http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#manipulating-data-s15)
to dictate how Hibernate constructs new objects.
What's more hairy is trying to extend the XMLBeans so that Hibernate has
the getter/setter methods it needs to map to primitive database types.
I have found no way of dealing with this other than just piping the
XMLBeans generated source through a perl script that modifies the actual
code, then recompile the source.
Also I've had problems with XMLBeans creating objects for nillable XML
elements and Hibernate thinks it's something it needs to store in the
database. I've had to wrap getter methods so that it checks for 0
length strings (.getStringValue()).
Everything I've done has been pretty kludgy, frankly.
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/