Unsubscribe
Re: ORM comparison
Hi Kashyap! Thank you for posting many good examples on the mailing list, and welcome to the PicoLisp world! > There is a plethora of ORM systems such as ActiveRecords (in Ruby/Rails) or > Microsoft EntityFramework and similar solutions in other languages where > Objects are mapped to SQL DB records. My thoughts on this subject is that ORM systems such as ActiveRecord and EntityFramework are there to map different technologies to one another, but the database in PicoLisp is "just" another form of symbols. ActiveRecord would map rows in a SQL database to Ruby objects and back, but there is not such a big difference between external and internal symbols in PicoLisp. Here, we have "symbols all the way down" instead of having to "massage" data between quite different forms. Personally, I find the Pil database one of the big advantages of the language. There is no longer any need to install, setup and administer a SQL database. I do not have context switch between objects on the one hand and tables and rows on the other. There is suddenly a consistent world to work in :) Best regards, Mattias -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: ORM comparison
Thanks Mattias, Yeah, intuitively, I do feel "symbols all the way down" makes Picolisp uniquely at an advantageous position. It would be good to be equipped with a way to articulate this advantage. Regards, Kashyap On Thu, Nov 28, 2019 at 11:28 AM Mattias Sundblad wrote: > Hi Kashyap! > > Thank you for posting many good examples on the mailing list, and > welcome to the PicoLisp world! > > > There is a plethora of ORM systems such as ActiveRecords (in Ruby/Rails) > or > > Microsoft EntityFramework and similar solutions in other languages where > > Objects are mapped to SQL DB records. > > My thoughts on this subject is that ORM systems such as ActiveRecord and > EntityFramework are there to map different technologies to one another, > but the > database in PicoLisp is "just" another form of symbols. > > ActiveRecord would map rows in a SQL database to Ruby objects and back, but > there is not such a big difference between external and internal symbols in > PicoLisp. Here, we have "symbols all the way down" instead of having to > "massage" data between quite different forms. > > Personally, I find the Pil database one of the big advantages of the > language. There is no longer any need to install, setup and administer a > SQL database. I do not have context switch between objects on the one > hand and tables and rows on the other. There is suddenly a consistent > world to work in :) > > Best regards, > > Mattias > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: ORM comparison
Hi Kashyap, I've a bit experience with ActiveRecord and some more with EntityFramework. As said in the other responses, the big fundamental difference between PicoLisp database architecture and ORMs is that in PicoLisp the application layer and the database layer is the same layer, it is not two very different conceptual systems (OOP vs. Relational) with a "translation system" in between. This results in several benefits when developing applications using PicoLisp database: * higher productivity o in PicoLisp, the database "table definition" and the application class is the same thing. In other stacks you have to do the "object definition" multiple times: in the database schema, an application class, usually you do additional a "business model" object (or even multiple). Every time it is basically the same "grouping of some properties/columns" with only small (but substantial) deviations. Even when these frameworks generate you some or all of the extra code, it is in practice often necessary to look at this code and adjust it so it works as intended, especially when doing changes on an existing application. * less code, less space for bugs o It is easier to analyze and debug what is happening with the data between input/storage and storage/output without having to track the values being copied from one intermediate (layer transition) object to the next. * simpler mental model o as less screws and mechanics are present in the PicoLisp stack, it is easier to understand and imagine in your head what does happen, easier to contrive which potential effects you need to take care of. o in mainstream stacks, the conceptual and technical barrier between OOP application programming and relational SQL database programming is often very pronounced. In my experience, application programmers these days often have a very incomplete understanding of how a database works (e.g. they don't know about transactions), which results in the best case in insufficient usage of the DBMS (e.g. amateurish re-implementing of functionality in the application which would be available from the DBMS in a tested, optimized and reliable way), or widespread disregard of fundamental data integrity vulnerabilities in the worst case, which depending of the application might result in minor annoyances up to complete and utter failure of the whole thing (e.g. losing vital data, might bankrupt a company). * queries and application cache o As you saw, it is possible to write very involved and powerful queries on the application level in PicoLisp. These queries make use of the database data cached on the "application layer", meaning the database is only asked for records which were not already accessed in the same session. o Most (maybe all?) ORMs cannot take advantage of the records they already have been cached, because the ORM has only a very limited implementation of SQL, so the query (e.g. written with LINQ on the application level) gets translated to SQL and sent to the database to be executed there, and then the results are sent back to the application - even data is sent forth and back which would already be cached on the application layer. + e.g. Entity Framework only uses its own cache when directly fetching a record by primary key (id), all other queries are executed on the database as Entity Framework has no query engine. + this hurts performance even more when the database is located on a different server than the application, as it is often the case. PicoLisp database is not relational: * there is no "primary key" in PicoLisp o while you might often have a (rel id (+Key +Number)) to have an simple index to find all records of the same entity, such a property is completely optional o a record only needs to be in at least one index or being linked to from another record, so it can be found and is not seen as garbage (as in garbage collecting = object to which nothing points) * every object has a global unique identifier o global per database o this is the name of the external symbol + which encodes the physical location in the database file where the record is stored o this makes it possible to directly link a record to another (also many to many) + in relational databases this requires a foreign key (which is an index, roughly comparable to +Ref) + in relational databases, many-to-many relations require an interim table # this interim table is usually
Re: ORM comparison
By the way, the often used the argument "ORM allows to switch from one (SQL) database to another" is illusory. In practice such a switch happens very rarely, and when it does it usually still needs much debugging and changes to the existing application because the different DBMS just work to differently even when they all talk a something similar-looking SQL-dialect, and most likely some DBMS-specific stuff was used in the application eventually (even when this means circumventing the ORM). Just think what it means that you could switch without any effect from one database management system to another - it means you very likely haven't fully utilized the previous DBMS and restricted yourself to the minimum functionality (lowest common denominator) shared by these very different SQL implementations. These arguments work only for simple cases, so they look nice and convincing on the powerpoint and marketing material, but they don't stand the test of reality. Kind regards, beneroth On 28.11.19 18:06, C K Kashyap wrote: > Hi Alex, > There is a plethora of ORM systems such as ActiveRecords (in > Ruby/Rails) or Microsoft EntityFramework and similar solutions in > other languages where Objects are mapped to SQL DB records. > > I'd love to know your thoughts about how PicoLisp's approach is > similar/different from them. > > Regards, > Kashyap -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: +QueryChart without pilog
On Thu, Nov 28, 2019 at 01:30:26PM +0100, Alexander Burger wrote: >(de f (Names) > (pilog > (quote > @Names Names > @Gen (mapcan '((Nm) (list 'nm '+TagVal Nm)) Names) > (select (@Item) >((@Gen (v +Tag) itm)) >... Haha, it just occurs to me that we made a stupid mistake! As we are searching for objects that have ALL names (i.e. an AND of all names in the list), searching the index multiple times (once for each element in the list) in very inefficient and unnecessary :) Instead, we can pick any element of the list, e.g. the CAR: (de f (Names) (pilog (quote @Names Names @Key (car Names) (select (@Item) ((nm +TagVal @Key (v +Tag) itm)) ... ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: +QueryChart without pilog
Oops, wait! On Thu, Nov 28, 2019 at 10:56:56AM +0100, Alexander Burger wrote: >(de f (Names) > (pilog > (quote > @Names Names > @Gen (mapcan '((C) (list 'nm '+TagVal C)) Colors) > (select (@Item) >((@Gen (v +Tag) itm)) >(lst @Nm @Item tgs v nm) >(member @Nm @Names) ) ) > (print-item @Item) ) ) This has a mistype (Colors instead of Names). Also, we need 'lst' plus 'val'. Better is: (de f (Names) (pilog (quote @Names Names @Gen (mapcan '((C) (list 'nm '+TagVal C)) Names) (select (@Item) ((@Gen (v +Tag) itm)) (lst @Tag @Item tgs) (val @Nm @Tag v nm) (member @Nm @Names) ) ) (print-item @Item) ) ) But not what you want, right? It is still OR, not AND ... ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: +QueryChart without pilog
Hi Kashyap, > Hurray!!! :) > Just to confirm if I've understood correctly - this solution is similar > to (nm +CuSu @Sup (sup +Item) (itm +Pos) ord) from the sample app correct? > Instead of (nm +CuSu @Sup) we have (nm +TagVal @Col1 nm +TagVal) - right? Yes, similar. The +CuSu case does: 1. fetch all +CuSu objects from the 'nm' tree whose names match the string in @Sup 2. use each object to index into the 'sup' tree (supplier) of items, to get these item objects 3. Index with the items into the position tree 4. Follow the joint from each found position to get its order object (nm +TagVal @Col1 nm +TagVal) is a bit truncated. The full generator was ((nm +TagVal @Col1 nm +TagVal @Col2) (v +Tag) itm) It traverses the 'nm' tree *two* times, first for color 1 and then for color 2. The found +TagVal objects are used to index into the 'v' tree of +Tag. > I need one more help - writing a function that take a list of strings > (Tags) and executes the pilog query with all the strings "anded" for > example, if I call (MakeQ "RED" BLUE" ) should return all items that have > three TAGs. > (de MakeQ Tags Better use (de MakeQ @ ..) or (de MakeQ (Tags) ..) to get evaluated arguments or argument list rspectively. > (let ( > Col '( (N) (intern (pack '@Col N))) 'intern' is not needed and not recommended. I would prepare the generator clauses as a Pilog variable, to build them at runtime, and then use the member/2 predicate in the filter clause to check for membership in the list of colors. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: +QueryChart without pilog
On Thu, Nov 28, 2019 at 11:45:23AM +0100, Alexander Burger wrote:
>(de f (Names)
> (pilog
> (quote
> @Names Names
> @Gen (mapcan '((C) (list 'nm '+TagVal C)) Names)
> (select (@Item)
>((@Gen (v +Tag) itm))
>(lst @Tag @Item tgs)
>(val @Nm @Tag v nm)
>(member @Nm @Names) ) )
> (print-item @Item) ) )
>
> But not what you want, right? It is still OR, not AND ...
This is tough to do in Pilog. As Prolog is not more than a tree *search* engine,
it is hard to prove that there is NO element in Names which canNOT be found in
the tags names.
It is surely possible, with 'or' and 'not' clauses plus cut operators, but I
don't find it at the moment.
So I would resort to Lisp in the filter:
(de f (Names)
(pilog
(quote
@Names Names
@Gen (mapcan '((Nm) (list 'nm '+TagVal Nm)) Names)
(select (@Item)
((@Gen (v +Tag) itm))
(^ @
(fully
'((Nm)
(find
'((This) (member Nm (: v nm)))
(; (-> @Item) tgs) ) )
(-> @Names) ) ) ) )
(print-item @Item) ) )
(f '("RED" "BLUE"))
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: +QueryChart without pilog
On Thu, Nov 28, 2019 at 10:44:15AM +0100, Alexander Burger wrote:
> I would prepare the generator clauses as a Pilog variable, to build them at
> runtime, and then use the member/2 predicate in the filter clause to check for
> membership in the list of colors.
Could not resist :) This works:
(de f (Names)
(pilog
(quote
@Names Names
@Gen (mapcan '((C) (list 'nm '+TagVal C)) Colors)
(select (@Item)
((@Gen (v +Tag) itm))
(lst @Nm @Item tgs v nm)
(member @Nm @Names) ) )
(print-item @Item) ) )
(f '("RED" "BLUE"))
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
ORM comparison
Hi Alex, There is a plethora of ORM systems such as ActiveRecords (in Ruby/Rails) or Microsoft EntityFramework and similar solutions in other languages where Objects are mapped to SQL DB records. I'd love to know your thoughts about how PicoLisp's approach is similar/different from them. Regards, Kashyap
Re: +QueryChart without pilog
Thank you so much Alex,
This works for me!
I think having the filter in lisp still lets us take
advantage of +QueryChart's efficiency over large sets right?
Regards,
Kashyap
On Thu, Nov 28, 2019 at 4:37 AM Alexander Burger
wrote:
> On Thu, Nov 28, 2019 at 11:45:23AM +0100, Alexander Burger wrote:
> >(de f (Names)
> > (pilog
> > (quote
> > @Names Names
> > @Gen (mapcan '((C) (list 'nm '+TagVal C)) Names)
> > (select (@Item)
> >((@Gen (v +Tag) itm))
> >(lst @Tag @Item tgs)
> >(val @Nm @Tag v nm)
> >(member @Nm @Names) ) )
> > (print-item @Item) ) )
> >
> > But not what you want, right? It is still OR, not AND ...
>
> This is tough to do in Pilog. As Prolog is not more than a tree *search*
> engine,
> it is hard to prove that there is NO element in Names which canNOT be
> found in
> the tags names.
>
> It is surely possible, with 'or' and 'not' clauses plus cut operators, but
> I
> don't find it at the moment.
>
> So I would resort to Lisp in the filter:
>
>(de f (Names)
> (pilog
> (quote
> @Names Names
> @Gen (mapcan '((Nm) (list 'nm '+TagVal Nm)) Names)
> (select (@Item)
>((@Gen (v +Tag) itm))
>(^ @
> (fully
> '((Nm)
> (find
>'((This) (member Nm (: v nm)))
>(; (-> @Item) tgs) ) )
> (-> @Names) ) ) ) )
> (print-item @Item) ) )
>
>(f '("RED" "BLUE"))
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: +QueryChart without pilog
On Thu, Nov 28, 2019 at 08:26:01AM -0800, C K Kashyap wrote: > I think having the filter in lisp still lets us take > advantage of +QueryChart's efficiency over large sets right? Yes, exactly. And it is faster than pure Pilog ;) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: +QueryChart without pilog
Super! Regards, Kashyap On Thu, Nov 28, 2019 at 8:39 AM Alexander Burger wrote: > On Thu, Nov 28, 2019 at 08:26:01AM -0800, C K Kashyap wrote: > > I think having the filter in lisp still lets us take > > advantage of +QueryChart's efficiency over large sets right? > > Yes, exactly. And it is faster than pure Pilog ;) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
