On 12 November 2012 11:13, Niphlod wrote:
With the jids= notation the current grid won't have any functional
> pagination,ordering, export, etc. That's because vars are not propagated. I
> sent a patch to Massimo for that a few days ago.
>
>
Thanks. I have used session variables to do that in th
With the jids= notation the current grid won't have any functional
pagination,ordering, export, etc. That's because vars are not propagated. I
sent a patch to Massimo for that a few days ago.
The question still stands: without using jids= and using only keywords=
"styled urls" when you click on
ok, give me some hints at least (trying to reverse engineer here :P).
when you go to http://localhost:8000/init/journal/journals how many records
are returned ? I assume 1.
in other words:
are you using request.vars.jids to create the query you pass on the tables ?
If yes, I remember someon
On 8 November 2012 15:32, Niphlod wrote:
> ehm missing something here. jids is not a standard var for the grid,
> are you using that var to filter the query passed to the grid ?
>
> One thing is taking care of the default filtering (keywords variable),
> another is to accomplish the same thin
ehm missing something here. jids is not a standard var for the grid,
are you using that var to filter the query passed to the grid ?
One thing is taking care of the default filtering (keywords variable),
another is to accomplish the same thing with a customization like that.
On Thursday,
what is the url you exported from ? (i.e. hover on the export link and
paste here (the relevant part is from the controller onwards))
On Thursday, November 8, 2012 11:08:11 AM UTC+1, Johann Spies wrote:
>
> On 7 November 2012 17:38, Niphlod > wrote:
>
>> patch to apply to trunk. Please test it ex
On 7 November 2012 17:38, Niphlod wrote:
> patch to apply to trunk. Please test it extensively with all the possible
> combinations.
>
I applied the patch but did not see any different behaviour.
A view with two records in the grid exported the whole table of more than
1 records.
And yes,
patch to apply to trunk. Please test it extensively with all the possible
combinations.
On Wednesday, November 7, 2012 2:23:35 PM UTC+1, Niphlod wrote:
>
> at that point you miss formatting fields and references. In addition,
> db.executesql() doesn't return an iterator either. You should code y
at that point you miss formatting fields and references. In addition,
db.executesql() doesn't return an iterator either. You should code your own
exporter using db._adapter.execute() and a yielding fetchone()s.
On Wednesday, November 7, 2012 2:01:45 PM UTC+1, Johann Spies wrote:
>
> On 7 Novembe
On 7 November 2012 15:01, Johann Spies wrote:
>
> In that case I would be inclined to use bypass DAL and db.executesql and
> use the backend to export to a file. That should be more efficient.
>
Sorry. That should read
... inclined to bypass DAL and use db.executesql ...
--
Because experienci
On 7 November 2012 14:05, Niphlod wrote:
> if your set doesn't fit into memory, saving it to a temp file won't get
> you out of troubles. One of DAL problems is that a Rows object does not
> return an iterator from the cursor, it's fetched all into memory first.
>
>
In that case I would be inclin
if your set doesn't fit into memory, saving it to a temp file won't get you
out of troubles. One of DAL problems is that a Rows object does not return
an iterator from the cursor, it's fetched all into memory first.
On Wednesday, November 7, 2012 12:45:46 PM UTC+1, Johann Spies wrote:
>
> On 7 N
far too magic to check for something that basically isn't trustable: even
if you code something like that and you check that there's x mb available,
another user can ask for another huge set of data and your "previoulsy"
free RAM is not free anymore.
On Wednesday, November 7, 2012 11:59:18 AM U
woking on 1.
for 2, how do you "foresee" how much time and RAM the present query will
take to be serialized ?
On Wednesday, November 7, 2012 11:25:29 AM UTC+1, Johann Spies wrote:
>
> On 7 November 2012 10:56, Niphlod > wrote:
>
>> uhm, good point on "if you want the entire table, just remove the
uhm, good point on "if you want the entire table, just remove the filters".
how to handle something that is impossible to handle (export a table with
so many rows that you can't export without timeouts or consuming
memory). just timeout ?
On Wednesday, November 7, 2012 2:17:02 AM UTC+1, howe
i agree that i expected the export buttons to export what is shown above.
if you want to export the whole table, remove all filters so that the whole
table is shown above and then click export.
(note that i do expect export to export all the rows that match the query
even if the table above is
FWIW, My users will be filtering test station settings to upload the csv to
thier test bench software. My users will need only thier own filtered data
in the CSVso big Me Too! here
--
I think it depends on how many records are in the table.
If you get a couple million rows, that's quite a load for a spread sheet to
import.
On Tuesday, November 6, 2012 9:24:26 AM UTC-5, Niphlod wrote:
>
> to me instead it's useful to let them download the whole table are we
> saying we
to me instead it's useful to let them download the whole table are we
saying we should support 6*2 = 12 formats (current 6, "with filters" and
"without filters") ? How would you name them ?
--
I would personally expect the export to give the representation only of the
fields I've made a query for.
On Tue, Nov 6, 2012 at 4:10 PM, Johann Spies wrote:
> On 6 November 2012 15:57, Niphlod wrote:
>
>> one sec.
>> export is meant to give the user the full resultset he can access (let's
>>
On 6 November 2012 15:57, Niphlod wrote:
> one sec.
> export is meant to give the user the full resultset he can access (let's
> say, offline consultation).
> Currently, only the "with hidden cols" exports honour the current query.
> Before calling it a bug we should agree on what functionalities
one sec.
export is meant to give the user the full resultset he can access (let's
say, offline consultation).
Currently, only the "with hidden cols" exports honour the current query.
Before calling it a bug we should agree on what functionalities expose on
the grid .
Il giorno martedì 6 novembr
OK
On Tuesday, November 6, 2012 3:35:10 PM UTC+2, Johann Spies wrote:
>
> On 6 November 2012 12:50, Aurelijus Useckas
>
> > wrote:
>
>> I want to export a certain query in SQLFORM.grid to a CSV, but once I
>> press on the (any) export option bellow the SQLFORM.grid, it exports the
>> whole tab
On 6 November 2012 12:50, Aurelijus Useckas wrote:
> I want to export a certain query in SQLFORM.grid to a CSV, but once I
> press on the (any) export option bellow the SQLFORM.grid, it exports the
> whole table and not just the ones meeting the certain criteria.
This must be viewed as a bug in
I want to export a certain query in SQLFORM.grid to a CSV, but once I press
on the (any) export option bellow the SQLFORM.grid, it exports the whole
table and not just the ones meeting the certain criteria.
Any ideas?
--
25 matches
Mail list logo
