Обсуждение: Recomended front ends?
I am in the process of defining an application for a very small company
that uses Postgresql for the backend DB. This DB will eventually run on a
hosted machine. As you imagine all of the employees have Windows machines
for their normal work asks. Frankly I am not very strong on Windows. so I
am wondering what the consensus is for creating forms and reports?
My first though is Libre Office as that is cross platform, and i can test
on my development Linux machine. However, i am getting a bit of push-back
from the user as he is having issues with installing Libre Office on his
computer. he says it does not play well with MS Office. Also we seem to be
having some bugs with Libre Office Base in early development.
What is the community wisdom here?
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
Hi, On Wed, Aug 7, 2019 at 1:57 PM stan <stanb@panix.com> wrote: > > I am in the process of defining an application for a very small company > that uses Postgresql for the backend DB. This DB will eventually run on a > hosted machine. As you imagine all of the employees have Windows machines > for their normal work asks. Frankly I am not very strong on Windows. so I > am wondering what the consensus is for creating forms and reports? > > My first though is Libre Office as that is cross platform, and i can test > on my development Linux machine. However, i am getting a bit of push-back > from the user as he is having issues with installing Libre Office on his > computer. he says it does not play well with MS Office. Also we seem to be > having some bugs with Libre Office Base in early development. > > What is the community wisdom here? What language/tools you are most comfortable with? Thank you. > > -- > "They that would give up essential liberty for temporary safety deserve > neither liberty nor safety." > -- Benjamin Franklin > >
On 8/7/19 11:57 AM, stan wrote: > I am in the process of defining an application for a very small company > that uses Postgresql for the backend DB. This DB will eventually run on a > hosted machine. As you imagine all of the employees have Windows machines > for their normal work asks. Frankly I am not very strong on Windows. so I > am wondering what the consensus is for creating forms and reports? > > My first though is Libre Office as that is cross platform, and i can test > on my development Linux machine. However, i am getting a bit of push-back > from the user as he is having issues with installing Libre Office on his > computer. he says it does not play well with MS Office. Also we seem to be > having some bugs with Libre Office Base in early development. Yeah, I gave up on Base awhile back due to its flaky performance. > > What is the community wisdom here? > What I have done is gone the Web route. In my case using Django as the framework/backend and the users browsers as the clients. That greatly simplifies keeping up with changes on the client end. There is still a need to deal with cross browser issues, but that is less of a chore. As Igor's post said it comes down to what you are comfortable with. -- Adrian Klaver adrian.klaver@aklaver.com
On 8/7/19 1:38 PM, Adrian Klaver wrote: > On 8/7/19 11:57 AM, stan wrote: >> I am in the process of defining an application for a very small company >> that uses Postgresql for the backend DB. This DB will eventually run >> on a >> hosted machine. As you imagine all of the employees have Windows >> machines >> for their normal work asks. Frankly I am not very strong on Windows. >> so I >> am wondering what the consensus is for creating forms and reports? >> >> My first though is Libre Office as that is cross platform, and i can >> test >> on my development Linux machine. However, i am getting a bit of >> push-back >> from the user as he is having issues with installing Libre Office on his >> computer. he says it does not play well with MS Office. Also we seem >> to be >> having some bugs with Libre Office Base in early development. > > Yeah, I gave up on Base awhile back due to its flaky performance. > >> >> What is the community wisdom here? >> > > What I have done is gone the Web route. In my case using Django as the > framework/backend and the users browsers as the clients. That greatly > simplifies keeping up with changes on the client end. There is still a > need to deal with cross browser issues, but that is less of a chore. > As Igor's post said it comes down to what you are comfortable with. > > > And if you choose to go down the web route, and you're not intimately familiar with at least one of the strands, get help immediately. There is much, much magic involved.
Hi, On Wed, Aug 7, 2019 at 1:57 PM stan <stanb@panix.com> wrote: > > I am in the process of defining an application for a very small company > that uses Postgresql for the backend DB. This DB will eventually run on a > hosted machine. As you imagine all of the employees have Windows machines > for their normal work asks. Frankly I am not very strong on Windows. so I > am wondering what the consensus is for creating forms and reports? > > My first though is Libre Office as that is cross platform, and i can test > on my development Linux machine. However, i am getting a bit of push-back > from the user as he is having issues with installing Libre Office on his > computer. he says it does not play well with MS Office. Also we seem to be > having some bugs with Libre Office Base in early development. > > What is the community wisdom here? On top of what already been said - make sure that the product you are about to start working on will have its requirements clear and concise. What is expected from the software? Does it needs to go out and access the web? Is the company split between different areas of the country/state? Does it needs to support Windows only? Will there be a need to a handheld device or bar code scanner? Will printing be involved? List is preliminary and can go on and on. Its just first that comes to mind. Get the requirements from the company management, make sure you understand them check you knowledge of different tools available and their support of the feature requested and start working. Good luck!! Thank you. > > -- > "They that would give up essential liberty for temporary safety deserve > neither liberty nor safety." > -- Benjamin Franklin > >
On Wed, 7 Aug 2019, Igor Korot wrote: > On top of what already been said - make sure that the product you are > about to start working on will have its requirements clear and concise. This is a critical process that needs to be developed in depth. One criterion that will guide your choice of UI is whether the database will be accessed only on the LAN or also remotely. For the former, consider using Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based application using Django. HTH, Rich
All excellent solutions, may I add Lucee to the list. We call it "the best web development system no-one knows about". Tim Clarke IT Director Direct: +44 (0)1376 504510 | Mobile: +44 (0)7887 563420 On 07/08/2019 21:38, Rich Shepard wrote: > On Wed, 7 Aug 2019, Igor Korot wrote: > >> On top of what already been said - make sure that the product you are >> about to start working on will have its requirements clear and concise. > > This is a critical process that needs to be developed in depth. One > criterion that will guide your choice of UI is whether the database > will be > accessed only on the LAN or also remotely. For the former, consider using > Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based > application using Django. > > HTH, > > Rich > > Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 | Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852 58031687 | Toronto: +1 647 503 2848 Web: https://www.manifest.co.uk/ Minerva Analytics Ltd - A Solactive Company 9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United Kingdom ________________________________ Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee youmust not use or disclose such information, instead please report it to admin@minerva.info<mailto:admin@minerva.info> Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The ManifestVoting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/for further information.
On Wed, 7 Aug 2019 at 20:57, stan <stanb@panix.com> wrote:
I am in the process of defining an application for a very small company
that uses Postgresql for the backend DB. This DB will eventually run on a
hosted machine. As you imagine all of the employees have Windows machines
for their normal work asks. Frankly I am not very strong on Windows. so I
am wondering what the consensus is for creating forms and reports?
My first though is Libre Office as that is cross platform, and i can test
on my development Linux machine. However, i am getting a bit of push-back
from the user as he is having issues with installing Libre Office on his
computer. he says it does not play well with MS Office. Also we seem to be
having some bugs with Libre Office Base in early development.
I went through this some months ago, and put out a similar query to this list.
It very much depends what type of app / data you are trying to address.
If you are considering something like Base: what your is users' level of expertise, and your appetite for distributing / maintaining / installing the app and it's infrastructure.
Options
I looked at several options, and ended up using Base as a quick and dirty front end to build a content management system for an eStore.
I looked at a few other options, including Kexi. Most I ruled out as they didn't seem to have active support communities.
One interesting looking one I played with a little was Kexi,but you need to build your database through Kexi (https://kde.org/applications/office/org.kde.kexi).
One of my constraining factors was that I didn't want Kexi to build the database for me, as I have a DB schema graphical design and generation tool I prefer to use (pgmodeler).
Bugs / features / learning curve
I didn't find any bugs in Base that caused me problems, more like missing features, or features that don't work the way I'd expected.
With a good Youtube series for a guide, I got a reasonable application up and running in a weekend. I do have a basic development background dating back to tools such as Oracle Forms, Mantis, and various other products of that ilk. Also have a little experience with MS Access, and Cobol and Java app generation.
End-user 'friendliness'
I would be a little wary of using Base for robust end-user data interaction, unless the users are fairly savvy on how to work with something like Base or Access applications. Things like deleting, inserting, and updating data on the forms are not all that intuitive at first, especially if you have multi-table forms (I have 4 tables embedded on my product form).
Some limitations
- You will need to be a bit aware of Base macro programming. Base does not have anything like VBA to work on.
- You will be limited on the type of application you can deliver. Basic data editing, probably suitable. Something more complex like selectable calendars, WYSIWYG text editors and so on, not so much. For example, I would love to include a markdown text editor for product descriptions (which Jekyll or Python can convert to HTML). Trivial in Vue.js or Quasar, not so much in Base, where I have to cut and paste the text to and from an editor.
- Using Base to search / navigate through large datasets is not very easy, and you need to think very carefully how you will design around this.
I am using my application quite regularly to maintain the data, but intend to replace it with a javascript (Vue and / or Quasar) front end at some stage.
One comment on the recommendations to create a web application, if you do not have current skills in Python or javascript and probably stuff like CSS / HTML the learning curve can be very time consuming.
Security:
Another issue is security. If the database is accessed within your corporate firewall, then it's not too bad. If you need to access it from across the internet using standard postgres drivers, then you may want to have a careful think as to how you can lock down access to the database. I allow postgres to communicate only to specific IP address ranges, and I also have the firewall set up to restrict access to port 5432 to a few specific IP ranges.
When it comes to pulling the product data out of the system, that's only through a GraphQL interface to a GraphQL server. That was pretty easy to generate. I pull the data out via a Python program, which in combination with Jekyll static site generator generates our 3 websites, The python program creates XML product file feeds to Jekyll, and in other cases generates the basic HTML product page for Jekyll to complete site generation.
For a weekend's work and a day or two of later enhancements, the Base app works pretty well.
To give you an idea of the complexity it consists of:
- Site: The domain name, the site base directory, discount and tax percentages
- Block to add / delete / display product categories applicable to the site
- Block to add / delete / display product categories applicable to the site
- Category: the product category, discount levels, and a set of attributes on where to place the generated data (XML catalog file name and directory, where product page templates are found and so on. category images are uploaded and displayed directly to / from the database on this page, and there is a block listing products within the category.
- Brand: Product brand management, including uploading / deleting / deleting brand logo images.
- Product: A full set of product attributes including covering all schema.org attributes and those required by Snipcart shopping cart, payment and shipping gateway.
- Product images uploaded / maintained
- Product categories block as a product can live in several places
There are a few other sundry pages to display or edit data in specific ways.
On 8/7/19 2:38 PM, Rich Shepard wrote: > On Wed, 7 Aug 2019, Igor Korot wrote: > >> On top of what already been said - make sure that the product you are >> about to start working on will have its requirements clear and concise. > > This is a critical process that needs to be developed in depth. One > criterion that will guide your choice of UI is whether the database will be > accessed only on the LAN or also remotely. For the former, consider using > Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based > application using Django. > > HTH, > > Rich I would be a little cautious about Django. Last time I checked, like many other web frameworks, it treats the database as just another component, one that provides data persistence for it, and consequently imposes its own constraints the schemas it will work with. Specifically IIRC it insists that tables have a single-column primary keys. If the client's existing database is already designed this way then that may not be a problem but if it has composite PKs then another option may be better. Flask is another relatively easy to use framework, can be used with or without Sqlalchemy but doesn't have the wealth of addons available with Django and being simpler requires more work to build the end application. There are of course many other framework options (Bottle, Web2Py, etc) Although it's been a decade plus since I worked with Microsoft products I had fairly good luck back then using Microsoft Access / VBA connected to a Postgresql backend via ODBC. Even back then MS's frontend development tools were way more advanced and easy to use than anything available for free in the Linux world. The downside was having to program in VBA but things may be much better these days with .NET et.al.
On 8/8/19 9:55 AM, Stuart McGraw wrote: > On 8/7/19 2:38 PM, Rich Shepard wrote: >> On Wed, 7 Aug 2019, Igor Korot wrote: >> >>> On top of what already been said - make sure that the product you are >>> about to start working on will have its requirements clear and concise. >> >> This is a critical process that needs to be developed in depth. One >> criterion that will guide your choice of UI is whether the database >> will be >> accessed only on the LAN or also remotely. For the former, consider using >> Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based >> application using Django. >> >> HTH, >> >> Rich > > I would be a little cautious about Django. Last time I checked, > like many other web frameworks, it treats the database as just another > component, one that provides data persistence for it, and consequently > imposes its own constraints the schemas it will work with. Specifically > IIRC it insists that tables have a single-column primary keys. If the > client's existing database is already designed this way then that may > not be a problem but if it has composite PKs then another option may > be better. Agreed the single-column PK is an annoyance, though it can be mitigated with unique_together. The real annoyance is: https://docs.djangoproject.com/en/1.11/ref/models/fields/#primary-key "The primary key field is read-only. If you change the value of the primary key on an existing object and then save it, a new object will be created alongside the old one." That being said I use Django with managed set to False on models and Sqitch doing the schema changes with no problems. Also Postgres is the reference database for Django and has a contrib module with Postgres specific features: https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/ > > Flask is another relatively easy to use framework, can be used with or > without Sqlalchemy but doesn't have the wealth of addons available with > Django and being simpler requires more work to build the end application. > There are of course many other framework options (Bottle, Web2Py, etc) > > Although it's been a decade plus since I worked with Microsoft products > I had fairly good luck back then using Microsoft Access / VBA connected > to a Postgresql backend via ODBC. Even back then MS's frontend development > tools were way more advanced and easy to use than anything available for > free in the Linux world. The downside was having to program in VBA but > things may be much better these days with .NET et.al. > > -- Adrian Klaver adrian.klaver@aklaver.com
On Thu, 8 Aug 2019, Stuart McGraw wrote: > I would be a little cautious about Django. > Specifically IIRC it insists that tables have a single-column primary > keys. Stuart, I looked seriously at Django and did not encounter that limitation. However, I did learn that I'm not a web application developer nor do I want to be. The applications I develop, primarily for my own business needs. use SQLAlchemy and that allows multi-column primary keys. That's a necessity for many-to-many tables (or SA classes). I suspect that Django also allows multi-column primary keys but the syntax might not be obvious. Regards, Rich
On 8/8/19 10:34 AM, Rich Shepard wrote: > On Thu, 8 Aug 2019, Stuart McGraw wrote: > >> I would be a little cautious about Django. > >> Specifically IIRC it insists that tables have a single-column primary >> keys. > > Stuart, > > I looked seriously at Django and did not encounter that limitation. > However, > I did learn that I'm not a web application developer nor do I want to be. > The applications I develop, primarily for my own business needs. use > SQLAlchemy and that allows multi-column primary keys. That's a necessity > for > many-to-many tables (or SA classes). > > I suspect that Django also allows multi-column primary keys but the syntax > might not be obvious. Unfortunately it does not: https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys Given that the issue: https://code.djangoproject.com/ticket/373 is 14 years old does not inspire confidence that it will change anytime soon. > > Regards, > > Rich > > -- Adrian Klaver adrian.klaver@aklaver.com
On Thu, 8 Aug 2019, Adrian Klaver wrote: > Unfortunately it does not: > https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys > > Given that the issue: > https://code.djangoproject.com/ticket/373 > is 14 years old does not inspire confidence that it will change anytime soon. Adrian, That's really interesting. I don't see how a framework cannot implement multi-column PKs. Many databases I have include tables for samples (geochemical, biological, physical) where the PK for each row is location, date, parameter. Good thing I don't like browser user interfaces, eh? :-) Thanks for the information, Rich
On 08/08/2019 17:55, Stuart McGraw wrote: > > I would be a little cautious about Django. Last time I checked, > like many other web frameworks, it treats the database as just another > component, one that provides data persistence for it, and consequently > imposes its own constraints the schemas it will work with. Specifically > IIRC it insists that tables have a single-column primary keys. If the > client's existing database is already designed this way then that may > not be a problem but if it has composite PKs then another option may > be better. > > Flask is another relatively easy to use framework, can be used with or > without Sqlalchemy but doesn't have the wealth of addons available with > Django and being simpler requires more work to build the end application. > There are of course many other framework options (Bottle, Web2Py, etc) > > Although it's been a decade plus since I worked with Microsoft products > I had fairly good luck back then using Microsoft Access / VBA connected > to a Postgresql backend via ODBC. Even back then MS's frontend > development > tools were way more advanced and easy to use than anything available for > free in the Linux world. The downside was having to program in VBA but > things may be much better these days with .NET et.al. We tried Django without any pleasant results. I'd also caution using MS Access, we're desperate to get away from it. Sharing code has challenges and it is horribly aggressive with caching unless you use un-bound forms and write all the CRUD interface code yourself. Tim Clarke Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 | Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852 58031687 | Toronto: +1 647 503 2848 Web: https://www.manifest.co.uk/ Minerva Analytics Ltd - A Solactive Company 9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United Kingdom ________________________________ Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee youmust not use or disclose such information, instead please report it to admin@minerva.info<mailto:admin@minerva.info> Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The ManifestVoting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/for further information.
On Thu, Aug 8, 2019 at 1:30 PM Tim Clarke <tim.clarke@minerva.info> wrote:
On 08/08/2019 17:55, Stuart McGraw wrote:
>
> I would be a little cautious about Django. Last time I checked,
> like many other web frameworks, it treats the database as just another
> component, one that provides data persistence for it, and consequently
> imposes its own constraints the schemas it will work with. Specifically
> IIRC it insists that tables have a single-column primary keys. If the
> client's existing database is already designed this way then that may
> not be a problem but if it has composite PKs then another option may
> be better.
>
> Flask is another relatively easy to use framework, can be used with or
> without Sqlalchemy but doesn't have the wealth of addons available with
> Django and being simpler requires more work to build the end application.
> There are of course many other framework options (Bottle, Web2Py, etc)
>
> Although it's been a decade plus since I worked with Microsoft products
> I had fairly good luck back then using Microsoft Access / VBA connected
> to a Postgresql backend via ODBC. Even back then MS's frontend
> development
> tools were way more advanced and easy to use than anything available for
> free in the Linux world. The downside was having to program in VBA but
> things may be much better these days with .NET et.al.
We tried Django without any pleasant results.
I'd also caution using MS Access, we're desperate to get away from it.
Sharing code has challenges and it is horribly aggressive with caching
unless you use un-bound forms and write all the CRUD interface code
yourself.
Tim Clarke
Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 | Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852 5803 1687 | Toronto: +1 647 503 2848
Web: https://www.manifest.co.uk/
Minerva Analytics Ltd - A Solactive Company
9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United Kingdom
________________________________
Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee you must not use or disclose such information, instead please report it to admin@minerva.info<mailto:admin@minerva.info>
Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The Manifest Voting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/ for further information.
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
'If at first you dont succeed, dont take up skydiving.'
On Thu, 8 Aug 2019, Tim Clarke wrote: > We tried Django without any pleasant results. Tim, That's unexpected and too bad. > I'd also caution using MS Access, we're desperate to get away from it. > Sharing code has challenges and it is horribly aggressive with caching > unless you use un-bound forms and write all the CRUD interface code > yourself. Slightly off-topic, but I've not seen anything good about Access. My understanding is it's a flat-file database intended as a user front end to Microsoft's relational database product. My experiences with those who use it have been painful. Just yesterday I downloaded a very large database of fisheries data from a federal agency and have started translating it to postgres using the mdbtools. There's no schema provided, only 32 pages of table columns and types without descriptions of the column names. No primary keys, no foreign keys, and only 66 tables were found in the .mdb file while all table names starting with s through z were not available. There are also many tables that hold redundant data which should not exist as the contents are easily generated by SQL queries. It will take me a while to make it a working relational database. Rich
All, No Web driven, but . . . . we’ve had some success with using LibreOffice(calc) as a frontend. Fairly easy to build forms,etc. Only limited experience so far, but was able to build domain lists from SQL calls, for form pulldown lists, etc. bobb > On Aug 8, 2019, at 2:10 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote: > > Think Before You Click: This email originated outside our organization. > > > On Thu, 8 Aug 2019, Tim Clarke wrote: > >> We tried Django without any pleasant results. > > Tim, > > That's unexpected and too bad. > >> I'd also caution using MS Access, we're desperate to get away from it. >> Sharing code has challenges and it is horribly aggressive with caching >> unless you use un-bound forms and write all the CRUD interface code >> yourself. > > Slightly off-topic, but I've not seen anything good about Access. My > understanding is it's a flat-file database intended as a user front end to > Microsoft's relational database product. My experiences with those who use > it have been painful. > > Just yesterday I downloaded a very large database of fisheries data from a > federal agency and have started translating it to postgres using the > mdbtools. There's no schema provided, only 32 pages of table columns and > types without descriptions of the column names. No primary keys, no foreign > keys, and only 66 tables were found in the .mdb file while all table names > starting with s through z were not available. There are also many tables > that hold redundant data which should not exist as the contents are easily > generated by SQL queries. It will take me a while to make it a working > relational database. > > Rich > > >
Hi,
After many years of using Oracle Forms and Oracle Reports with Oracle DB, I have been using Lazarus and "Code Typhon"
for many years now.
Both work with Free Pascal Compiler and both are open source and free.
Both have a very good IDE, the code produced is Pascal (very easily readable), and they connect directly to many DBMS including PostgreSQL, Oracle, MSSQL, SQLITE, etc..
After many years of using Oracle Forms and Oracle Reports with Oracle DB, I have been using Lazarus and "Code Typhon"
for many years now.
Both work with Free Pascal Compiler and both are open source and free.
Both have a very good IDE, the code produced is Pascal (very easily readable), and they connect directly to many DBMS including PostgreSQL, Oracle, MSSQL, SQLITE, etc..
You can find information here: https://en.wikipedia.org/wiki/Lazarus_(IDE)
and here: https://www.pilotlogic.com/sitejoom/
Also here: https://en.wikipedia.org/wiki/Lazarus_(IDE)
you can find some interesting information.
Also here: https://www.getlazarus.org/learn/tutorials/intro/
"If you are haven't used Lazarus recently then this tutorial is for you. In it we give users a broad overview of Lazarus
and some of its key features. We look at the type of applications you can create with Lazarus, and show you the core
concepts to desktop application development it makes so very easy.
and some of its key features. We look at the type of applications you can create with Lazarus, and show you the core
concepts to desktop application development it makes so very easy.
Highlights include the two way design process, events handlers, testing and debugging, and deployment.
A brief gallery of applications I've personally created with Lazarus is included at the end, and I honestly believe it's
the best tool in the world for developing platform agnostic desktop applications. Like the video says, give Lazarus a try."
A brief gallery of applications I've personally created with Lazarus is included at the end, and I honestly believe it's
the best tool in the world for developing platform agnostic desktop applications. Like the video says, give Lazarus a try."
Dias Costa
On 08-08-2019 20:26, Basques, Bob (CI-StPaul) wrote:
All, No Web driven, but . . . . we’ve had some success with using LibreOffice(calc) as a frontend. Fairly easy to build forms, etc. Only limited experience so far, but was able to build domain lists from SQL calls, for form pulldown lists, etc. bobbOn Aug 8, 2019, at 2:10 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote: Think Before You Click: This email originated outside our organization. On Thu, 8 Aug 2019, Tim Clarke wrote:We tried Django without any pleasant results.Tim, That's unexpected and too bad.I'd also caution using MS Access, we're desperate to get away from it. Sharing code has challenges and it is horribly aggressive with caching unless you use un-bound forms and write all the CRUD interface code yourself.Slightly off-topic, but I've not seen anything good about Access. My understanding is it's a flat-file database intended as a user front end to Microsoft's relational database product. My experiences with those who use it have been painful. Just yesterday I downloaded a very large database of fisheries data from a federal agency and have started translating it to postgres using the mdbtools. There's no schema provided, only 32 pages of table columns and types without descriptions of the column names. No primary keys, no foreign keys, and only 66 tables were found in the .mdb file while all table names starting with s through z were not available. There are also many tables that hold redundant data which should not exist as the contents are easily generated by SQL queries. It will take me a while to make it a working relational database. Rich
-- J. M. Dias Costa Telef. 214026948 Telem. 939307421 Se divulgar esta mensagem por terceiros, por favor: 1. Apague o meu endereço de correio electrónico e o meu nome. 2. Apague também os endereços dos seus amigos antes de distribuir. 3. Enderece como cópia oculta (Cc ou Bcc) para os SEUS destinatários. Agindo deste modo, dificultará a disseminação de "vírus", "spams" e "banners" e contribuirá para manter a privacidade de todos e cada um. Obrigado. Nota: Não se deverá ao acaso a ocorrência de palavras na minha escrita que não respeitem o malfadado acordo ortográfico.
For web/mobile applications we use Mojolicious, https://mojolicious.org witch work pretty well with Postgresql, is written in Perl and has plenty of nice features.
Paolo Saudin
Il giorno gio 8 ago 2019 alle ore 22:09 DiasCosta <diascosta@diascosta.org> ha scritto:
Hi,
After many years of using Oracle Forms and Oracle Reports with Oracle DB, I have been using Lazarus and "Code Typhon"
for many years now.
Both work with Free Pascal Compiler and both are open source and free.
Both have a very good IDE, the code produced is Pascal (very easily readable), and they connect directly to many DBMS including PostgreSQL, Oracle, MSSQL, SQLITE, etc..
You can find information here: https://en.wikipedia.org/wiki/Lazarus_(IDE)
and here: https://www.pilotlogic.com/sitejoom/
Also here: https://en.wikipedia.org/wiki/Lazarus_(IDE)
you can find some interesting information.
Also here: https://www.getlazarus.org/learn/tutorials/intro/"If you are haven't used Lazarus recently then this tutorial is for you. In it we give users a broad overview of Lazarus
and some of its key features. We look at the type of applications you can create with Lazarus, and show you the core
concepts to desktop application development it makes so very easy.Highlights include the two way design process, events handlers, testing and debugging, and deployment.
A brief gallery of applications I've personally created with Lazarus is included at the end, and I honestly believe it's
the best tool in the world for developing platform agnostic desktop applications. Like the video says, give Lazarus a try."
Dias Costa
On 08-08-2019 20:26, Basques, Bob (CI-StPaul) wrote:All, No Web driven, but . . . . we’ve had some success with using LibreOffice(calc) as a frontend. Fairly easy to build forms, etc. Only limited experience so far, but was able to build domain lists from SQL calls, for form pulldown lists, etc. bobbOn Aug 8, 2019, at 2:10 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote: Think Before You Click: This email originated outside our organization. On Thu, 8 Aug 2019, Tim Clarke wrote:We tried Django without any pleasant results.Tim, That's unexpected and too bad.I'd also caution using MS Access, we're desperate to get away from it. Sharing code has challenges and it is horribly aggressive with caching unless you use un-bound forms and write all the CRUD interface code yourself.Slightly off-topic, but I've not seen anything good about Access. My understanding is it's a flat-file database intended as a user front end to Microsoft's relational database product. My experiences with those who use it have been painful. Just yesterday I downloaded a very large database of fisheries data from a federal agency and have started translating it to postgres using the mdbtools. There's no schema provided, only 32 pages of table columns and types without descriptions of the column names. No primary keys, no foreign keys, and only 66 tables were found in the .mdb file while all table names starting with s through z were not available. There are also many tables that hold redundant data which should not exist as the contents are easily generated by SQL queries. It will take me a while to make it a working relational database. Rich-- J. M. Dias Costa Telef. 214026948 Telem. 939307421 Se divulgar esta mensagem por terceiros, por favor: 1. Apague o meu endereço de correio electrónico e o meu nome. 2. Apague também os endereços dos seus amigos antes de distribuir. 3. Enderece como cópia oculta (Cc ou Bcc) para os SEUS destinatários. Agindo deste modo, dificultará a disseminação de "vírus", "spams" e "banners" e contribuirá para manter a privacidade de todos e cada um. Obrigado. Nota: Não se deverá ao acaso a ocorrência de palavras na minha escrita que não respeitem o malfadado acordo ortográfico.
On 2019-08-08 10:47:47 -0700, Rich Shepard wrote: > On Thu, 8 Aug 2019, Adrian Klaver wrote: > > Unfortunately it does not: > > https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys > > > > Given that the issue: > > https://code.djangoproject.com/ticket/373 > > is 14 years old does not inspire confidence that it will change anytime soon. > > Adrian, > > That's really interesting. I don't see how a framework cannot implement > multi-column PKs. You are a database guy. You have a database and want to write an application for it. Even in a greenfield project, you probably do the database design first. (I know I do) The Django framwork comes from the opposite direction. The programmers aren't expected to know much about relational databases[1]. They are expected to write their application and Django provides (among other things like session and form handling) a persitence layer which happens to be backed by a relational database. So Django's ORM layer isn't intended to deal with any possible (or even any reasonable) database model - just with database models generated by Django. Django lets you use "unmanaged" tables, but it is quite noticeable that this isn't the primary use case. > Many databases I have include tables for samples (geochemical, biological, > physical) where the PK for each row is location, date, parameter. Good thing > I don't like browser user interfaces, eh? :-) Django isn't the only web framework. hp [1] It should be noted, however, that the Django ORM is what Joel Spolsky calls a leaky abstraction. If you are ignorant about how RDBMSs work, your application will probably be horrendously slow. Even if you do know this, you often have to bend over backwards to get reasonable performance. -- _ | Peter J. Holzer | we build much bigger, better disasters now |_|_) | | because we have much more sophisticated | | | hjp@hjp.at | management tools. __/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
Вложения
On Sun, Aug 11, 2019 at 7:49 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote: > Django lets you use "unmanaged" tables, but it is quite noticeable that > this isn't the primary use case. It isn't, but it's the best way to use Django for database-literate people. It's enough to ignore the Django sale pitch of the database as a replaceable element and just assume Postgres. In Docker times you don't need SQLite to create a poorly representative "development database". You can just ignore the Django ORM for the whole data-definition layer and migrations: you can have your database schema, with comments, in your source code, with strict control of what's in the db (exotic index definitions, exclusion constraints, writable views...) and only use the ORM to read and manipulate data, as long as the Django model "resembles" the database table. Schema migrations are easy to deal with using SQL patches [1], and complete, unlike any Model-based migration system. Using the Django ORM to create complex queries is a joy (especially nesting subqueries), and you don't lose all the other Django facilities (decent auth model, decent CRUD interface, customisation when "decent" is not enough). [1] https://gist.github.com/dvarrazzo/4161070 -- Daniele
On 8/27/19 8:04 AM, Daniele Varrazzo wrote: > On Sun, Aug 11, 2019 at 7:49 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote: > >> Django lets you use "unmanaged" tables, but it is quite noticeable that >> this isn't the primary use case. > > It isn't, but it's the best way to use Django for database-literate > people. It's enough to ignore the Django sale pitch of the database as > a replaceable element and just assume Postgres. In Docker times you > don't need SQLite to create a poorly representative "development > database". Django takes Postgres as it's reference database which makes things easier, especially when you add in contrib.postgres(https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/) > > You can just ignore the Django ORM for the whole data-definition layer > and migrations: you can have your database schema, with comments, in > your source code, with strict control of what's in the db (exotic > index definitions, exclusion constraints, writable views...) and only > use the ORM to read and manipulate data, as long as the Django model > "resembles" the database table. > Schema migrations are easy to deal with using SQL patches [1], and > complete, unlike any Model-based migration system. +1 > > Using the Django ORM to create complex queries is a joy (especially > nesting subqueries), and you don't lose all the other Django > facilities (decent auth model, decent CRUD interface, customisation > when "decent" is not enough). > > [1] https://gist.github.com/dvarrazzo/4161070 > > -- Daniele > > > -- Adrian Klaver adrian.klaver@aklaver.com
On 2019-08-27 16:04:02 +0100, Daniele Varrazzo wrote:
> Using the Django ORM to create complex queries is a joy (especially
> nesting subqueries),
Not for me. I usually know what SQL I want to execute. Then I have to
convert that SQL into a weird[1] and limited query language composed of
method calls so that the ORM can turn it into SQL again (hopefully
something close to the SQL I had in mind). It hurts my brain.
hp
[1] Well, SQL is weird, too. But it is weird in an "invented 40+ years
ago and grown organically since" way, not a "constrained by the syntax
of a different language" way.
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | hjp@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
Вложения
On 2019-08-27 08:16:08 -0700, Adrian Klaver wrote: > Django takes Postgres as it's reference database which makes things easier, > especially when you add in > contrib.postgres(https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/) Looks nice. hp -- _ | Peter J. Holzer | we build much bigger, better disasters now |_|_) | | because we have much more sophisticated | | | hjp@hjp.at | management tools. __/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>