Re: Good news: the end of a nonsensical dream

[Edward K. Ream]

On Mon, May 6, 2019 at 12:08 PM Rob  wrote:

> Perhaps it's not on the top of your priority list. However, I for one,
> would appreciate seeing a demo example of your approach to this; complete
> with db hooks and some query examples.
>

I'll do this soon.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Rob]

Perhaps it's not on the top of your priority list. However, I for one, 
would appreciate seeing a demo example of your approach to this; complete 
with db hooks and some query examples.

Rob...

On Monday, May 6, 2019 at 11:18:34 AM UTC-4, Edward K. Ream wrote:
>
>
> It's easy to access an existing database via Python's sqlite3 module 
> . It's so easy that the 
> only remaining question is what to do with query results.  I've already 
> explained how I might approach this topic, but you are free to handle query 
> results any way you like.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Edward K. Ream]

On Monday, May 6, 2019 at 8:22:51 AM UTC-5, Josef wrote:

Leo already has reasonable CSV support via the "edit-pane-csv" command, 
> thanks to Terry.
> This could be improved if the CSV header line could be "frozen", so it 
> shows even when scrolling down in the CSV table.
>

It's easy to access an existing database via Python's sqlite3 module 
. It's so easy that the 
only remaining question is what to do with query results.  I've already 
explained how I might approach this topic, but you are free to handle query 
results any way you like.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Josef]

Leo already has reasonable CSV support via the "edit-pane-csv" command, 
thanks to Terry.
This could be improved if the CSV header line could be "frozen", so it 
shows even when scrolling down in the CSV table.

IMHO, this is of limited use unless one can also scroll horizontally, hide 
columns, filter rows etc. You end up with a large subset of Excel. I 
usually use LibreOffice calc for this, although it too has annoying 
misfeatures, like automatic spelling correction and type (date, number) 
recognition, which makes it a pain to use on plain CSV files.

For storing structured data in a text file I find JSON acceptable and YAML 
too complicated. I myself prefer Lua files to store structured data, and 
read it into Python with the lupa module (the data files return a table 
with "return {...}", so it becomes easy to read them with dofile and to 
check the syntax with lua. This works well when the data is to be edited by 
hand, especially when your data is better represented in a tree than in a 
table.

For large, programmatically generated databases, better use a real SQL or 
NoSQL database to store the data.

It would be interesting to use Leo as a database front-end, like Edward 
suggests (I currently use "DB Browser for SQLite" for this purpose).
Perhaps the Leo would be more suited as a front-end to NoSQL databases, 
though.

- Josef


On Saturday, May 4, 2019 at 7:25:24 PM UTC+2, Arjan wrote:
>
> I'd also be very interested in this.
>
> Also related, this earlier thread on Using Leo as a database 
>  - 
> I'd love to hear followup on that.
>
> I'd prefer having the result set of a query (multiple rows) inside a 
> single node body, but I think improved handling of CSV-like data would be 
> needed to make this more useful.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Edward K. Ream]

On Sat, May 4, 2019 at 12:25 PM Arjan  wrote:

> I'd also be very interested in this.
>
> Also related, this earlier thread on Using Leo as a database
>  -
> I'd love to hear followup on that.
>
> I'd prefer having the result set of a query (multiple rows) inside a
> single node body, but I think improved handling of CSV-like data would be
> needed to make this more useful.
>

No changes to Leo are required.  I'll create a demo script when I can.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Arjan]

I'd also be very interested in this.

Also related, this earlier thread on Using Leo as a database 
 - 
I'd love to hear followup on that.

I'd prefer having the result set of a query (multiple rows) inside a single 
node body, but I think improved handling of CSV-like data would be needed 
to make this more useful.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Edward K. Ream]

On Monday, April 29, 2019 at 5:51:01 AM UTC-5, Edward K. Ream wrote:

The idea is to put the results of queries in Leo nodes.  Something like 
this:

- Headline is a short summary of the query
  - @query body text contains actual query.
  - One or more nodes whose bodies contain the results of the query.

This would be more Leonine:

- @query: Headline summarizes the query. Body contains the actual query.
  - One or more nodes whose bodies contain the results of the query.

In other words:

- The @query node can both summarize the query and contain the actual query.
- Each result should be a separate child of the @query node.

Edward

>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Edward K. Ream]

On Sun, Apr 28, 2019 at 1:53 PM Rob  wrote:

I'm very much interested in figuring out how to use Leo as a sort of
> 'frontend' to a db, where nodes might contain queries which generate
> results in other nodes which could be deleted at will as the source data is
> preserved in the db itself.
>

Yes.  This is exactly the way I envisage using db's in Leo.

The idea is to put the results of queries in Leo nodes.  Something like
this:

- Headline is a short summary of the query
  - @query body text contains actual query.
  - One or more nodes whose bodies contain the results of the query.

Depending on the size of the results, you might want to put them all in one
node, or put each result in its own node.

All this should be straightforward using p.insertAfter or
p.insertAsLastChild.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Good news: the end of a nonsensical dream

[Rob]

Thanks for this post, Edward. I also dabbled around using Leo as an actual 
db (though very much smaller data sets), with not much success. I tried 
storing data using YAML, but it's very clunky and not efficient.

I'm very much interested in figuring out how to use Leo as a sort of 
'frontend' to a db, where nodes might contain queries which generate 
results in other nodes which could be deleted at will as the source data is 
preserved in the db itself.

Is anyone else here actually doing something like that? If so, perhaps 
share ideas on where to get started. Maybe an example Leo file and db in 
the contrib branch?

Rob...


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.