<div dir="ltr"><div>I will add identities and some of the other standard references and constraints as well this weekend as well as the requisite tests and documentation. <br></div><div><br></div><div>I might actually also get testing finalized on easy creation of read-only roles, editor roles and admin roles where you can limit access to certain databases, certain schemas or certain tables. <br></div><div><br></div><div>Sabra. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 10:43 AM Timo Myyrä <<a href="mailto:timo.myyra@bittivirhe.fi">timo.myyra@bittivirhe.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sabra Crolleton <<a href="mailto:sabra.crolleton@gmail.com" target="_blank">sabra.crolleton@gmail.com</a>> writes:<br>
<br>
> Hi Timo,<br>
><br>
> I can probably add the identity column stuff to daos this weekend and that<br>
> would solve your first issue. I have to admit that I do not use daos (just<br>
> sql or s-sql), so they have never been a high priority for me.<br>
><br>
> With respect to references and foreign keys to other tables, I can also try<br>
> to write up an explanation this weekend, but please understand that<br>
> postmodern daos are really simple. They are not full ORMs. Maybe someone<br>
> else on the mailing list can write up how they use them.<br>
><br>
<br>
Yeah, my use cases seem bit cleaner with few daos and some more direct sql. Daos<br>
seem nice until you get to more complex queries and then they seem to add just<br>
confusion. At least thats been my experience from moving to manually mapping raw<br>
sql query results to objects vs. heavy use of ORM library. It would be great if<br>
identity gets added to daos. Would make things a bit more consistent.<br>
<br>
> From a design standpoint, I agree that I would not include user passwords<br>
> in a dao class with the rest of the user information. (I do hope those are<br>
> salted passwords as well.) That also implies that passwords should not be<br>
> in the same table as the rest of the user information. However, your<br>
> password validation function just needs the user id and the password to be<br>
> tested. Why pass around an entire user dao? (This shows my biases as a dba<br>
> rather than a developer.)<br>
><br>
> But I am confused by your comment about adding a method to a user dao<br>
> class. Common lisp classes do not have methods. Methods are generic and are<br>
> specialized on their parameters. So I could write a validate-password<br>
> generic function that takes two parameters, a user-id and a password<br>
> string. Then I would write two methods, one that accepted an integer as the<br>
> user-id parameter and a second method that accepted a user-dao as the<br>
> user-id parameter (and then internally extracted the user-id out of the<br>
> user dao). See, e.g. the explanations here:<br>
> <a href="http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html" rel="noreferrer" target="_blank">http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html</a><br>
><br>
> Sabra<br>
<br>
By "adding method to class" I meant adding generic function method specializing<br>
to user dao. But as pointed out, probably seem a bit too 'complex' when regular<br>
function will work as well.<br>
<br>
Well, perhaps the code structure starts to become clearer once my project<br>
progresses.<br>
<br>
timo<br>
<br>
><br>
> On Tue, Jun 9, 2020 at 4:01 PM Timo Myyrä <<a href="mailto:timo.myyra@bittivirhe.fi" target="_blank">timo.myyra@bittivirhe.fi</a>> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> So the best bet would be to just use the create-table to create the<br>
>> database<br>
>> structure and then define dao classes separately.<br>
>> I was trying to avoid that as I'd guess it will be easy to have<br>
>> definitions given on<br>
>> create-table and dao class to drift apart. I was trying to avoid that by<br>
>> using<br>
>> just dao so database stuff would be given on just one place.<br>
>><br>
>> But now that we're talking daos, how should I handle references to other<br>
>> tables<br>
>> with dao class? If we take the User dao class for example, I add the users<br>
>> table<br>
>> and define the user dao. I have then separate passwords table that stores<br>
>> user<br>
>> passwords. It doesn't feel right to make passwords an dao class. The<br>
>> passwords<br>
>> are tied very tighly to user so it would seeem logical to query the<br>
>> passwords with user<br>
>> dao. What would be 'idiomatic way' to do this with postmodern? Just use<br>
>> the user dao<br>
>> class and add an method to it, which makes normal sql query for users<br>
>> passwords?<br>
>> Just define password dao and query it with user id?<br>
>><br>
>> A bit basic questions. The documents and examples show small cases so its<br>
>> hard<br>
>> to see the big picture from them.<br>
>><br>
>> timo<br>
>><br>
>> Sabra Crolleton <<a href="mailto:sabra.crolleton@gmail.com" target="_blank">sabra.crolleton@gmail.com</a>> writes:<br>
>><br>
>> > Hello Timo,<br>
>> ><br>
>> > A couple of notes here. First "user" is a restricted word for postgresql,<br>
>> > so I<br>
>> > suggest naming the table "users" instead.<br>
>> ><br>
>> > Second, your s-sql sample create table misplaced a paren. You need<br>
>> another<br>
>> > paren after<br>
>> > the username column and before the primary key<br>
>> ><br>
>> > I agree that daos do not yet have identity columns, but that really only<br>
>> > prevents you from creating a table using the dao.<br>
>> ><br>
>> > So consider the following where we create a table using s-sql, insert<br>
>> some<br>
>> > items,<br>
>> > demonstrate that we can retrieve an item using a dao, then demonstrate we<br>
>> > can<br>
>> > create a dao item, insert it in the table and then retrieve it.<br>
>> Postgresql<br>
>> > handles all<br>
>> > the identity stuff. Also note that I used "users" as the table, but I can<br>
>> > create a dao class<br>
>> > named "user".<br>
>> ><br>
>> > (query (:create-table (:if-not-exists 'users)<br>
>> > ((id :type integer :identity-always t)<br>
>> > (username :type text))<br>
>> > (:primary-key id)))<br>
>> ><br>
>> > (query (:insert-rows-into 'users :columns 'username :values '(("Jason")<br>
>> > ("Tim") ("Karolyn"))))<br>
>> ><br>
>> > (defclass user ()<br>
>> > ((id :col-type integer :accessor id)<br>
>> > (username :col-type text :initarg :username :accessor username))<br>
>> > (:metaclass dao-class)<br>
>> > (:table-name users)<br>
>> > (:keys id))<br>
>> ><br>
>> > (username (get-dao 'user 1))<br>
>> > "Jason"<br>
>> ><br>
>> > (let ((item (make-instance 'user :username "Zenya")))<br>
>> > (insert-dao item))<br>
>> ><br>
>> > (username (get-dao 'user 4))<br>
>> ><br>
>> > "Zenya"<br>
>> ><br>
>> > Does this help?<br>
>> ><br>
>> > Sabra Crolleton<br>
>> ><br>
>> ><br>
>> > On Tue, Jun 9, 2020 at 12:41 PM Timo Myyrä <<a href="mailto:timo.myyra@bittivirhe.fi" target="_blank">timo.myyra@bittivirhe.fi</a>><br>
>> wrote:<br>
>> ><br>
>> >> Hi,<br>
>> >><br>
>> >> I'm learning to use postmodern as part of my hobby project but I've hit<br>
>> a<br>
>> >> small bump in the process.<br>
>> >> I can have the identity column defined for table without dao with<br>
>> >> something like:<br>
>> >> (s-sql:sql (:create-table (:if-not-exists 'user)<br>
>> >> ((id :type int :identity-always t)<br>
>> >> (username :type text)<br>
>> >> (:primary-key id)))<br>
>> >><br>
>> >> But I intent to use dao classes so it would be nice to have identity<br>
>> >> column specified as part to defclass slot options.<br>
>> >> Is there some way to create dao class with identity column?<br>
>> >><br>
>> >> Br,<br>
>> >> Timo M<br>
>> >><br>
>> >><br>
>><br>
</blockquote></div>