pride-users — A forum for information exchange all around the usage of PriDE

Re: [Pride-users] Java Persistence API (JPA)

[Jan L. <jle...@gm...>]

Hi Anders
Ok, I think I see what you have in mind. That means that you don't 
suggest to extend PriDE in general but only the entity generator.
Yes of course, it should be pretty easy to extend the generator in a way 
that it also produces JPA compliant code annotations. I would even say 
that - if your are planing to implement parts of JPA on top of PriDE - 
the extemsion of the entity generator were the easiest part ;-)

Just take a look at the generator code which follows the template method 
design pattern and therefore can easily be extended. If you need a 
helping hand, just let me know. If you can specify exactly which 
annotations you'd like to have supported, we may find someone who does 
the job. But of course you are invited to contribute the corresponding 
extension by your own :-)

Regards,
Jan

Anders Peterson wrote:

> My intention are unclear, but something like this... (people get 
> strange ideas)
>
> 1) I'd like to do a (my own) JPA implementaion with PriDE as a 
> building block. Using PriDE I've had to write code for caching, 
> relationship management and other things.  I'm thinking that maybe I'm 
> already well on my way to JPA compliance.
>
> 2) I don't necessarily need full JPA compliance. PriDE (with my 
> extensions) does not need to be fully JPA compliant (a drop in 
> replacement for any other JPA implementation), but I should be able to 
> replace "my code" with some/any other JPA implementation.
>
> 3) JPA users will need an entity bean generator - PriDE already has 
> one (ant task and eclipse plugin). Adding support for JPA annotations 
> can't be too much work. If I (or someone else) would like to try what 
> I mentioned above having a PriDE tools that generates JPA compliant 
> entity beans would help. Perhaps you can see supplying a JPA entity 
> bean generator as marketing for PriDE.
>
> /Anders

Re: [Pride-users] Java Persistence API (JPA)

[Anders P. <and...@op...>]

My intention are unclear, but something like this... (people get strange 
ideas)

1) I'd like to do a (my own) JPA implementaion with PriDE as a building 
block. Using PriDE I've had to write code for caching, relationship 
management and other things.  I'm thinking that maybe I'm already well 
on my way to JPA compliance.

2) I don't necessarily need full JPA compliance. PriDE (with my 
extensions) does not need to be fully JPA compliant (a drop in 
replacement for any other JPA implementation), but I should be able to 
replace "my code" with some/any other JPA implementation.

3) JPA users will need an entity bean generator - PriDE already has one 
(ant task and eclipse plugin). Adding support for JPA annotations can't 
be too much work. If I (or someone else) would like to try what I 
mentioned above having a PriDE tools that generates JPA compliant entity 
beans would help. Perhaps you can see supplying a JPA entity bean 
generator as marketing for PriDE.

/Anders

Jan Lessner wrote:
> Hi Anders
> I'm not shure what your intention is when asking for JPA compliance in 
> PriDE. The toolkit follows some general design rules which are 
> fundamentally different to what the mainstream of Java O/R mapping 
> propagates to be state of the art. JPA perfectly represents that 
> mainstream and therefore can easily be adopted by the famous toolkits 
> like e.g. Hibernate or OJB. PriDE must be seen as an alternative, not 
> only concerning the implementation of a particular standard API but as 
> an alternative *approach* for O/R mapping. The approach is based on 
> the design principles which are explained in
>
>    http://pride.sourceforge.net/PriDE-Inside.html
>
> and which contradict to what is required for JPA compliance. The most 
> important difference is that fact, that PriDE does not manage any 
> persistence objects but treats everything as a pure value object. This 
> is the key for using SQL as query language and it implies that there 
> is no support for transparent relationship management and that load 
> and stire operations must be performed explicitely. Changing these 
> design principles would mean to totally redesign PriDE and loose it's 
> central uniqueness: simplicity. You won't find any other O/R mapping 
> toolkit which is so small and easy to maintain and to adapt to 
> personal needs like PriDE. PriDE was developed for teams with a 
> vertical organization which requires every developer to understand 
> (and potentially debug) in a few hours how the persistence manager 
> works. So you see that it is a matter of philosophy why PriDE doesn't 
> follow the JPA standard.
> It is one of the most important advantages of the Java world: knowing 
> to have alternatives :-)
>
> Regards,
> Jan
>
>
>
> Anders Peterson wrote:
>
>> Hi,
>>
>> Are there any plans to make PriDE JPA compatible?
>>
>> I know the idea behind PriDE is not to do all that full JPA 
>> compliance would require, but is it possible that the parts that 
>> PriDE actually does do are made JPA compatible?
>>
>> Could for instance the eclipse plugin and ant tasks generate beans 
>> with all the correct annotations?
>>
>> PriDE leaves you to design and implement some of the more advanced 
>> features. I'm interested in trying to that in a JPA compatible way. 
>> It would help me if the generated beans have the annotations.
>>
>> /Anders
>>  
>>
>


-- 
http://ojalgo.org/

Mathematics, Linear Algebra and Optimisation with Java

Re: [Pride-users] Java Persistence API (JPA)

[Jan L. <jle...@gm...>]

Hi Anders
I'm not shure what your intention is when asking for JPA compliance in 
PriDE. The toolkit follows some general design rules which are 
fundamentally different to what the mainstream of Java O/R mapping 
propagates to be state of the art. JPA perfectly represents that 
mainstream and therefore can easily be adopted by the famous toolkits 
like e.g. Hibernate or OJB. PriDE must be seen as an alternative, not 
only concerning the implementation of a particular standard API but as 
an alternative *approach* for O/R mapping. The approach is based on the 
design principles which are explained in

    http://pride.sourceforge.net/PriDE-Inside.html

and which contradict to what is required for JPA compliance. The most 
important difference is that fact, that PriDE does not manage any 
persistence objects but treats everything as a pure value object. This 
is the key for using SQL as query language and it implies that there is 
no support for transparent relationship management and that load and 
stire operations must be performed explicitely. Changing these design 
principles would mean to totally redesign PriDE and loose it's central 
uniqueness: simplicity. You won't find any other O/R mapping toolkit 
which is so small and easy to maintain and to adapt to personal needs 
like PriDE. PriDE was developed for teams with a vertical organization 
which requires every developer to understand (and potentially debug) in 
a few hours how the persistence manager works. So you see that it is a 
matter of philosophy why PriDE doesn't follow the JPA standard.
It is one of the most important advantages of the Java world: knowing to 
have alternatives :-)

Regards,
Jan



Anders Peterson wrote:

>Hi,
>
>Are there any plans to make PriDE JPA compatible?
>
>I know the idea behind PriDE is not to do all that full JPA compliance 
>would require, but is it possible that the parts that PriDE actually 
>does do are made JPA compatible?
>
>Could for instance the eclipse plugin and ant tasks generate beans with 
>all the correct annotations?
>
>PriDE leaves you to design and implement some of the more advanced 
>features. I'm interested in trying to that in a JPA compatible way. It 
>would help me if the generated beans have the annotations.
>
>/Anders
>  
>

[Pride-users] Java Persistence API (JPA)

[Anders P. <and...@op...>]

Hi,

Are there any plans to make PriDE JPA compatible?

I know the idea behind PriDE is not to do all that full JPA compliance 
would require, but is it possible that the parts that PriDE actually 
does do are made JPA compatible?

Could for instance the eclipse plugin and ant tasks generate beans with 
all the correct annotations?

PriDE leaves you to design and implement some of the more advanced 
features. I'm interested in trying to that in a JPA compatible way. It 
would help me if the generated beans have the annotations.

/Anders

[Pride-users] Using ResourceAccessorWeb

[<jle...@gm...>]

Anders,
The ResourceAccessorWeb is supposed to be used in a Web container which 
is part of a J2EE application server and therefore has access to SQL 
databases by means of DataSources. If you are not familiar with these 
things or working with a pure servlet engine like Tomcat, you can just 
go on using ResourceAccessorJ2SE. The disadvantage is that you don't 
have a sophisticated connection pooling and distributed transaction 
management at hand. However, if you actually need things like that you 
are strongly recommended to use a managed server environment. It is part 
of PriDE's philosophy not to implement any mentionable resource 
management by itself but to rely on appropriate infrastructure which is 
already available in every J2EE server.

Cheers,
Jan


Anders Peterson schrieb:

> Hi Jan, and I hope you had a nice holiday.
>
> I'm trying to use ResourceAccessorWeb, and don't understand the part 
> about JNDI and              
> DatabaseFactory.setDatabaseName("java:comp/env/sampledb");
>
>
> If my connection URL "normally" is:
>
> jdbc:sybase:Tds:qs01:2638?ServiceName=GenOLFData
>
> Then how do I know what the database name should be?
>
>
> (I have things working with ResourceAccessorJ2SE.)
>
> /Anders

Re: [Pride-users] Re: [Wicket-user] Re: Tools and frameworks

[Anders P. <and...@op...>]

Hi Jan, and I hope you had a nice holiday.

I'm trying to use ResourceAccessorWeb, and don't understand the part=20
about JNDI and 			=20
DatabaseFactory.setDatabaseName("java:comp/env/sampledb");


If my connection URL "normally" is:

jdbc:sybase:Tds:qs01:2638?ServiceName=3DGenOLFData

Then how do I know what the database name should be?


(I have things working with ResourceAccessorJ2SE.)

/Anders
--=20
http://ojalgo.org/

Java Algorithms for Mathematics, Linear Algebra and Optimisation

Jan Le=DFner wrote:
> Hello everybody.
>=20
> I would suggest to have a look in the PriDE examples folder. There is a=
=20
> example of how to use PriDE from within a servlet engine, independently=
=20
> from the engine's specific features. Maybe this helps you along. The=20
> example uses are hard-coded configuration which you can simply modify t=
o=20
> a variant reading a property file from the class path and feed the=20
> properties to the PriDE initialization.
>=20
> Regards,
> Jan
>=20
>=20
> Anders Peterson schrieb:
>=20
>> Eelco Hillenius wrote:
>>
>>> You can't specify VM arguments in your web.xml file. You can use=20
>>> web.xml parameters in your Wicket application object (override method=
=20
>>> init). You should note however that VM arguments are in the scope of=20
>>> the whole VM that can have mutliple (conflicting?) webapplications.=20
>>> So, you probably want to avoid depending on VM in production systems=20
>>> unless you are really sure you 'own' the server.
>>
>>
>>
>> Ok.
>>
>> The class/method that reads the properties doesn't access=20
>> System.getProperty("aProp") directly. Instead it takes an argument of=20
>> type Properties. So, there is no problem.
>>
>> Having multiple databases, for one app, is not a problem either.
>>
>> http://pride.sourceforge.net/PriDE-Introduction.html#AccessingMultiple=
Databases=20
>>
>>
>> /Anders

Re: [Pride-users] Re: [Wicket-user] Re: Tools and frameworks

[Eelco H. <eel...@to...>]

About PriDE... It wasn't on my radar until today. Just looked at it and 
it passed the 5 minutes test (which means that I understood how to use 
it within 5 minutes). Cool! Not sure if I am ready to live without 
relation support, but having worked with OJB and Hibernate for a few 
years now, I have to agree that relation support can be serious cause of 
all kinds of not-so-obvious problems too.

Cheers,

Eelco


Jan Leßner wrote:

> Hello everybody.
>
> I would suggest to have a look in the PriDE examples folder. There is 
> a example of how to use PriDE from within a servlet engine, 
> independently from the engine's specific features. Maybe this helps 
> you along. The example uses are hard-coded configuration which you can 
> simply modify to a variant reading a property file from the class path 
> and feed the properties to the PriDE initialization.
>
> Regards,
> Jan
>
>
> Anders Peterson schrieb:
>
>> Eelco Hillenius wrote:
>>
>>> You can't specify VM arguments in your web.xml file. You can use 
>>> web.xml parameters in your Wicket application object (override 
>>> method init). You should note however that VM arguments are in the 
>>> scope of the whole VM that can have mutliple (conflicting?) 
>>> webapplications. So, you probably want to avoid depending on VM in 
>>> production systems unless you are really sure you 'own' the server.
>>
>>
>>
>> Ok.
>>
>> The class/method that reads the properties doesn't access 
>> System.getProperty("aProp") directly. Instead it takes an argument of 
>> type Properties. So, there is no problem.
>>
>> Having multiple databases, for one app, is not a problem either.
>>
>> http://pride.sourceforge.net/PriDE-Introduction.html#AccessingMultipleDatabases 
>>
>>
>> /Anders
>
>
>
>

Re: [Pride-users] Re: [Wicket-user] Re: Tools and frameworks

[<jle...@gm...>]

Hello everybody.

I would suggest to have a look in the PriDE examples folder. There is a 
example of how to use PriDE from within a servlet engine, independently 
from the engine's specific features. Maybe this helps you along. The 
example uses are hard-coded configuration which you can simply modify to 
a variant reading a property file from the class path and feed the 
properties to the PriDE initialization.

Regards,
Jan


Anders Peterson schrieb:

> Eelco Hillenius wrote:
>
>> You can't specify VM arguments in your web.xml file. You can use 
>> web.xml parameters in your Wicket application object (override method 
>> init). You should note however that VM arguments are in the scope of 
>> the whole VM that can have mutliple (conflicting?) webapplications. 
>> So, you probably want to avoid depending on VM in production systems 
>> unless you are really sure you 'own' the server.
>
>
> Ok.
>
> The class/method that reads the properties doesn't access 
> System.getProperty("aProp") directly. Instead it takes an argument of 
> type Properties. So, there is no problem.
>
> Having multiple databases, for one app, is not a problem either.
>
> http://pride.sourceforge.net/PriDE-Introduction.html#AccessingMultipleDatabases 
>
>
> /Anders

Re: [Pride-users] Questions from a new user

[<jle...@gm...>]

Hi Anders
I'm just back from holiday, so excuse the delay of my answers to some of 
your questions. I put my comments in between.

Thanks for you details feedback and suggestions in general.

Cheers,
Jan


> What is required to get support for Sybase ASA? What exactly does it 
> mean that you support a specific database? I managed to get things 
> working (what I've seen so far) by setting dbtype to SQLSERVER. 
> (Sybase ASA has been meade largely compatible with ASE, and MS SQL 
> Server is based on an early version of ASE.) 

Unfortunately, there are some things in SQL which have never been 
perfectly standardized but are left to the database vendor to some 
degree. Probably the best-known example for that is the format for date 
values in SQL insert and update statements. PriDE must therefore be 
configured to "speak the vendor-specific" slang of SQL in some cases. 
There are actually not too many different slangs around, so specifiying 
one of the officially supported ones might very well work for others 
too, just as you experienced with your Sybases database.
If you want to be sure that everything is working well, you should 
execute PriDE's JUnit test suite on your database.

> One thing that could be improved in the documentation is how to set up 
> the database connection. Explicitly stating which properties to set 
> would help. I have it working so obviously it could be deduced from 
> reading the docs and/or the code, but it can be made easier.

Good idea. I just checked the documentation and there is actually no 
explicite list of available configuration parameters. I'll improve the 
documentation accordingly.

> Regarding the convenience classes DatabaseAdapter, DatabaseRecord, 
> ObjectAdapter, MappedObject and ValueObjectAdapter as well as the 
> eclipse plugin:
> 1) You're giving us too much convenience. ;-)

That's a matter of history ;-)

> 2) Most methods in DatabaseAdapter are declared "protected static". 
> Isn't that an odd combination? Why not make them "public static" and 
> reference them statically. 

Well, if you walk along the derivation hirarchy it makes a lot of sense 
to me. DatabaseAdapter is supposed to be used as a base class only and 
therefore has only protected methods. The two default derivations 
ObjecteAdapter and DatabaseRecord both use these functions. Which 
oddness do you see in there?

> 3) The eclipse plugin should generate classes with two "public static 
> final" attributes called DESCRIPTOR and KEY_FIELDS. 

Why? Currently these members are generated *protected* because they are 
supposed to be used only internally or by derived adapters. This seems 
reasonable to me.

> In the Database class I'm missing a method:
> fetchRecord(String[] dbkeyfields, Object obj, RecordDescriptor red)
>
> Having it would make that class more complete/consistent. 

Yes, could be added, of course? On the other hand, the access methods of 
that class are very seldomly used. Do you have a particular access 
problem in mind when asking for this function?

Re: [Pride-users] Re: [Wicket-user] Re: Tools and frameworks

[Anders P. <and...@op...>]

Eelco Hillenius wrote:
> You can't specify VM arguments in your web.xml file. You can use web.xml 
> parameters in your Wicket application object (override method init). You 
> should note however that VM arguments are in the scope of the whole VM 
> that can have mutliple (conflicting?) webapplications. So, you probably 
> want to avoid depending on VM in production systems unless you are 
> really sure you 'own' the server.

Ok.

The class/method that reads the properties doesn't access 
System.getProperty("aProp") directly. Instead it takes an argument of 
type Properties. So, there is no problem.

Having multiple databases, for one app, is not a problem either.

http://pride.sourceforge.net/PriDE-Introduction.html#AccessingMultipleDatabases

/Anders
-- 
http://ojalgo.org/

Java Algorithms for Mathematics, Linear Algebra and Optimisation

[Pride-users] Re: [Wicket-user] Re: Tools and frameworks

[Eelco H. <eel...@to...>]

You can't specify VM arguments in your web.xml file. You can use web.xml 
parameters in your Wicket application object (override method init). You 
should note however that VM arguments are in the scope of the whole VM 
that can have mutliple (conflicting?) webapplications. So, you probably 
want to avoid depending on VM in production systems unless you are 
really sure you 'own' the server.

Eelco

Anders Peterson wrote:

> Well... ;-)
>
> (I'm a beginner both in terms of PriDE and servlets.)
>
> Currently I simply set the VM arguments in the eclipse (Jetty 
> Launcher) launch configuration.
>
> Before, when I was using Tomcat/Sysdeo, I couldn't do this. Then I 
> hard coded the properties:
>
> System.setProperty("pride.driver", "com.sybase.jdbc2.jdbc.SybDriver");
> ...
>
>
> Can't I specify VM arguments in the web.xml file?
>
>
> /Anders

[Pride-users] Re: Tools and frameworks

[Anders P. <and...@op...>]

Well... ;-)

(I'm a beginner both in terms of PriDE and servlets.)

Currently I simply set the VM arguments in the eclipse (Jetty Launcher) 
launch configuration.

Before, when I was using Tomcat/Sysdeo, I couldn't do this. Then I hard 
coded the properties:

System.setProperty("pride.driver", "com.sybase.jdbc2.jdbc.SybDriver");
...


Can't I specify VM arguments in the web.xml file?


/Anders
-- 
http://ojalgo.org/

Java Algorithms for Mathematics, Linear Algebra and Optimisation


Gwyn Evans wrote:
> Hmm, out of interest, how are you specifying the DB details when
> running PriDE from a web-app, as the docs I saw seemed to suggest this
> would require system properties set at app startup?  Other than that,
> it looked interesting, although I also mean to have a look at Spring's
> JDBC support...
> 
> /Gwyn

[Pride-users] Questions from a new user

[Anders P. <and...@op...>]

Hi,


I'm just starting to use PriDE, and have a few questions and comments.


What is required to get support for Sybase ASA? What exactly does it 
mean that you support a specific database? I managed to get things 
working (what I've seen so far) by setting dbtype to SQLSERVER. (Sybase 
ASA has been meade largely compatible with ASE, and MS SQL Server is 
based on an early version of ASE.)


One thing that could be improved in the documentation is how to set up 
the database connection. Explicitly stating which properties to set 
would help. I have it working so obviously it could be deduced from 
reading the docs and/or the code, but it can be made easier.

For any new users raeding the list archices; these are my VM arguments:
-Dpride.driver="com.sybase.jdbc2.jdbc.SybDriver"
-Dpride.url="jdbc:sybase:Tds:qs01:2638?ServiceName=GenOLFData"
-Dpride.user="dba"
-Dpride.password="sql"
-Dpride.dbtype="sqlserver"

Code examples in the docs use pride.db instead of pride.url. I think 
"url" is a better name than "db", and since I had to write the code 
accessing that property myself anyway...


Regarding the convenience classes DatabaseAdapter, DatabaseRecord, 
ObjectAdapter, MappedObject and ValueObjectAdapter as well as the 
eclipse plugin:
1) You're giving us too much convenience. ;-)
2) Most methods in DatabaseAdapter are declared "protected static". 
Isn't that an odd combination? Why not make them "public static" and 
reference them statically.
3) The eclipse plugin should generate classes with two "public static 
final" attributes called DESCRIPTOR and KEY_FIELDS.


In the Database class I'm missing a method:
fetchRecord(String[] dbkeyfields, Object obj, RecordDescriptor red)

Having it would make that class more complete/consistent.


Hope you don't think I'm complaining, and thanks for making PriDE open 
source.

/Anders

Re: [Pride-users] LAST_INSERT_ID in mysql or access to select @@identity

[<jle...@gm...>]

Peter,
Although there is currently no support for that in PriDE it may be 
interesting to know that this is an issue of on-going development. I 
recently got a contribution with the required code extensions for that 
feature and we are planning to incorporate the changes in the next 
weeks. So the next release in May will have that inside.

Until that day, you could add your own extension pretty quickly:

 - extend function Database.sqlUpdate to get passed an array of 
auto-fields from function Database.createRecord
 - in Database.sqlUpdate, call Statement.executeUpdate(String 
<cid:par...@gm...> sql, String 
<cid:par...@gm...>[] columnNames) rather than 
executeUpdate(String sql), passing the array of auto-fields as second 
parameter
 - call Statement.getAutoGeneratedKeys() after successful SQL execution
 - return the ResultSet from getAutoGeneratedKeys to Database.createRecord
 - add a function RecordDescriptor.record2object which  gets passed the 
ResultSet, the target object and the auto field array to extract these 
field's values from the result set.

This is how the code will look like in the extended version. It takes 
some knowledge about PriDE's source of course but it will probably don't 
take more then 20 lines of code :-)

Regards,
Jan


Peter Girard schrieb:

> Is there a way to get the id of the last inserted record, if the 
> record has an auto increment column?
>
> thanks

[Pride-users] LAST_INSERT_ID in mysql or access to select @@identity

[Peter G. <qa...@ho...>]

Is there a way to get the id of the last inserted record, if the record has 
an auto increment column?

thanks

[Pride-users] Re: Issues/Problems with code generated by Pride Eclipse plug-in

[<jle...@ma...>]

Joseph
Thanks a lot for the information. In fact I never used this bugfinder
plugin before and I looks very interesting to me what it suggests. Let me
try to comment some of the suggestions:

> This Eclipse Plug-in(http://findbugs.sourceforge.net/) found some
> Issues/Problems with the generated Java code.
> You might/might not include these changes to your Pride Eclipse
> plug-in
>
> ICD0_Before is the code generated by your plug-in. ICD0_After has the
> FindBugs suggested changes. I also included an additional constructor
> for the Class.
>
> sql2.txt is the DDL used to create the table within HSQLDB.
>
> Change 1:  Line 10 Include the final clause
This is ok for most cases of course (lets say 99.99999%), so I guess we
will adopt this to the generator. On the other hand it should be kept in
mind that it is one of PriDE's advantages that records descriptors can be
dynamically constructed and modified at runtime. We use this sometimes to
construct dynamic table joins depending on query criteria. However I admit
that we usually don't modify the static version of a descriptor ;-)

> Change 2: Line 26 use the method .clone() to return the String Array
Ok, I see the point of potential misuse. But isn't that a bit overcareful ;-)

> Change 3: Added a serialVersionUID variable after the RecordDescriptor
> getDescriptor() method. The Serialable interface likes to have it.
Yes, ok.

> Change 4: Replace keyword Long with long (3 occurences)
I don't agree at this point. The corresponding column in the table was
declared as BIGINT, allowing null values. So the data type to be used in
the Java entity must also be one which supports null values. I guess the
generator is right here. What do you think?

> Change 5: Added a new Constructor that adds a  record and uses a
> small-case version of the field autofields
I'm not so shure here. We explicitly left out a constructor like this in
the entity generator because it usually produces a very ugly method
signature with lots of parameters for each field which is not an auto
field (i.e. the majority). If we would do so, we'd probably get complains
from other people saying that their code metrics plugins whould not except
the generated code ;-)

Well. We will see how we can incorporate the results of your analysis.

Regards,
Jan

[Pride-users] Re: PriDE

[<jle...@ma...>]

Hi Franco
Ok, I will have a look at it, but I will need your help for DB2 tests
because I have currently no installation available. I will post you an
appropriate improvement until end of this week, ok? If it works well, I
will prepare a minor update for PriDE with the fix.

Cheers,
Jan


> Jan,
>
> thanks for the answer,
> I looked into, but is not simple to change without knowledge of all the
> classes, maybe you can do it better as me,
> you should chek at the decimal digigt if NUMERIC, like this,
>
> ...
> DatabaseMetaData dmd = User.getSQLConnection().getMetaData();
> ResultSet rs = dmd.getColumns( getCatalog(), getSchema(), getName(), null
> );
> ...
> int decimals = rs.getInt( "DECIMAL_DIGITS" );
> ...
>
> then if NUMERIC and decimals > 0
> ...
> returnType = "java.math.BigDecimal";
>
> Thanks
>
> jle...@ma... wrote:
>
>>Franco,
>>The type mapping is performed in class de.mathema.pride.util.TableColumns
>>by function getType(). It is just a big switch-case-cascade, so it should
>>be very simple for you to modify it according to your needs.
>>
>>Regards,
>>Jan
>>
>>
>>PS: There is a PriDE mailing list available on SourceForge which you
>>usually get faster response from ;-)
>>
>>
>>
>>>hello,
>>>just run little test on DB2/400,
>>>I see some generation problem on decimal field mapped to long,
>>>can you point me to the class that do the class generation to look for a
>>>fix ?
>>>
>>>Thanks
>>>
>>>--
>>>-----------------------------------------------------------------------------
>>>*** This messages was scanned for malicious contents ***
>>>-----------------------------------------------------------------------------
>>>Franco Biaggi
>>>CH-6807 Taverne
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
> --
> -----------------------------------------------------------------------------
> *** This messages was scanned for malicious contents ***
> -----------------------------------------------------------------------------
> Franco Biaggi
> CH-6807 Taverne
>
>

[Pride-users] [Fwd: Re: PriDE]

[<jle...@ma...>]

Franco,
The type mapping is performed in class de.mathema.pride.util.TableColumns
by function getType(). It is just a big switch-case-cascade, so it should
be very simple for you to modify it according to your needs.

Regards,
Jan


> hello,
> just run little test on DB2/400,
> I see some generation problem on decimal field mapped to long,
> can you point me to the class that do the class generation to look for a
fix ?
>
> Thanks
>
> --
> -----------------------------------------------------------------------------
*** This messages was scanned for malicious contents ***
> -----------------------------------------------------------------------------
Franco Biaggi
> CH-6807 Taverne
>
>

[Pride-users] Re: Extension Descriptor and documentation enhancement

[<jle...@gm...>]

Hello everybody here
Please find attached some answers for a few questions from the past.

> Hi,
> I"m (still) using PriDE quite extensively, and I stumbled upon some 
> issues, which I wanted to communicate.
> 
> 1) I think it should be noted in the javadoc of SQLExpression that the 
> following code is perfectly valid:
>  
>     exp = exp.and("some_colname",
>                   SQLExpression.Operator.BETWEEN,
>                   (Object) new Long[]
>                   {pObj.getLeft(), pObj.getRight()});
Ok, the Javadocs have been improved accordingly.
  
>  I think it would be even better, to add an extra and() and or() method 
>  to avoid this nasty casting of an array to an object.
Hmm. The casting should not be required because a Java array *IS* an object.
Passing a Long array should lead to a unique method identification.

>  2) What are ExtensionDescriptors? They are in the code, but mentioned 
>  nowhere.
Extension descriptors are a relict from PriDE's early days. We didn't dare
ro remove them but don't recommend to use them either. The idea is to extend
an object by an undetermined number of additional optional attributes which
can dynamically be allocated and assigned or removed. These values are stored
in a separate table of key-value-pairs. This approach is conseptually interesting
because it supports real polymorphism on relational databases. However, from
the view of performance and database structure it is a mess.

>  3) I think it would be nice, to have some kind of "native" support of 
>  ORDER BY expressions in PriDE. I need to apply an ORDER BY to statements 
>  very often in my application. I resolved this, by extending the 
>  RecordDescriptor"s getConstraint() method, and appending the appropriate 
>  ORDER BY at every invocation. Maybe something like this could go into 
>  the core of PriDE (I can give you the code, I used).
Yes, would probably be useful and not too difficult. I would suggest that a feature
like this should best fit into SQLExpression. I'm not so shure about adding it to
the RecordDescriptor class because I don't see ORDER BY as being somehow object-type-
related.

What do you think?


>  That"s it for now, thanks for providing such a nice and easy framework.
You're welcome ;-)

Cheers,
Jan

[Pride-users] Extension Descriptor and documentation enhancement

[Benjamin R. <fir...@us...>]

Hi,
I'm (still) using PriDE quite extensively, and I stumbled upon some 
issues, which I wanted to communicate.

1) I think it should be noted in the javadoc of SQLExpression that the 
following code is perfectly valid:

   exp = exp.and("some_colname",
                 SQLExpression.Operator.BETWEEN,
                 (Object) new Long[]
                 {pObj.getLeft(), pObj.getRight()});

I think it would be even better, to add an extra and() and or() method 
to avoid this nasty casting of an array to an object.

2) What are ExtensionDescriptors? They are in the code, but mentioned 
nowhere.

3) I think it would be nice, to have some kind of "native" support of 
ORDER BY expressions in PriDE. I need to apply an ORDER BY to statements 
very often in my application. I resolved this, by extending the 
RecordDescriptor's getConstraint() method, and appending the appropriate 
ORDER BY at every invocation. Maybe something like this could go into 
the core of PriDE (I can give you the code, I used).


That's it for now, thanks for providing such a nice and easy framework.

Benjamin