Hi Eric,
Yes i always uses OpenJump. And I tried to do accept as GIS tools by
my society (a big europeen insurance society).
Nice ! Would be interesting to know more about your use case.
If I resume the situation: handle identifier( sequence) by integers is
not sure ( I don't understand why, but I trust you )
Just say that casting a database bigint (64 bits) to a java int (32 bit)
may change the value. Database id
can be more than 2^32, and truncating the value is unsafe, especially
for an identifier.
but for others values is preferable because requests are less long to
write.
For count() it is less unsafe because there is only small chance that a
user query a table with more than 2^32 rows.
But in the general case, if a user store bigint values in its database,
I would consider unsafe to cast it to an integer.
PostgreSQL jdbc implementation can't retrive key or primary key
information about table?
Yes it can. You're right.
Handle sequence with object and other bigint with integer.
Right, it would be possible to have different behaviours for bigint PK
and for other bigint.
As it is not a very simple solution, and not completely satisfying
(still convert long to int),
I wonder it it wouldn't be better to add Long type to Attribute.Type.
An other subject can I help you on the new postgis driver? Do you have
a road map?
Hopefully, I will have a beta and a bit of documentation before the end
of the month.
Thanks for the proposition, I'll let you know.
Working on OpenJUMP datatypes (adding Boolean or Long) is a recurrent topic.
I think it is a big work because it has side effect on all I/O
framework, but if you
have ideas and time to work on the topic, you're welcome.
Michaël
Kinds regards
Eric Lemesre (de mon Androïde)
Le 2 oct. 2013 22:24, "Michaël Michaud" <michael.mich...@free.fr
<mailto:michael.mich...@free.fr>> a écrit :
Hi Eric,
Nice to see you still use OpenJUMP ;-)
Currently, I'm not in favour of this change and have a few reasons :
I'm working on a new postgis driver where I need to manage
database identifiers.
Often, database identifiers use bigint (from sequence). bigint are
naturally
converted to java long and I choose to encapsulate it into an
Object (it has been
converted to a String until september 2013).
Casting a bigint to an int does not seem safe enough to me. For a
count
operation, it is ok as we rarely manage more than 1M features in
OJ, but for
identifiers, it would be really unsafe.
Moreover, it is quite easy to cast count() to int explicitely with
for example
"SELECT code, count (*)::integer as nb FROM anyTable GROUP BY 1"
I have also tested to cast AttributeType.OBJECT to
AttributeType.INTEGER
afterwards in the schema editor, and it seems to work well.
Other opinions ?
Michaël
Hi,
in com.vividsolutions.jump.datastore.jdbc.ValueConverterFactory
Currently the bigint in database table is transcribed into a
String object type.
But the default type of aggregation is also bigint.
for example:
SELECT code_departement, count (*) as nb
FROM anyTable
GROUP BY 1
nb has bigint!
I think we should change the type attribute has
AttributType.Object to AttributType.INTERGER
What is your opinion on the subject?
regards
Eric
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
<mailto:Jump-pilot-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get
the most from
the latest Intel processors and coprocessors. See abstracts and
register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
<mailto:Jump-pilot-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
